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Notational Conventions 


Most of the references to system calls in the text and graphics use C syntax instead 
of PL/M (for example, the system call send_message instead of send$message). If 
you are working in C, you must use the C header files, rmx_c.h, udi_c.h, and 
rmx_err.h. If you are working in PL/M, you must use dollar signs ($) and use the 
rmxplm.ext and error. lit header files. 

This manual uses the following conventions: 


iS> Note 

Notes indicate important information. 

A CAUTION 

Cautions indicate situations which may damage hardware or data. 


4 



Contents 


1 Basic Concepts 

iRMX Operating System Features 12 

Real-time Processing 12 

Multitasking 13 

Preemptive, Priority-based Scheduling 14 

Interrupt Processing 16 

Predictable Response Time 18 

Multiprogramming 19 

Objects and System Calls 21 

Intertask Coordination and Communication 23 

Memory Pools and Memory Sharing 26 

Virtual Memory Allocation With the Paging Subsystem 27 

System Calls 27 

Operating System Layers 28 

Example Code and Demonstration Programs 30 

Network Support 31 

32-Bit Architecture, Addressing, and Protection 32 

Bus Architecture Support 34 

iRMX for Windows Special Features 35 

iRMX for PCs Special Features 36 


2 Nucleus and Kernel Features 

Nucleus Objects 37 

Jobs 38 

Object Directories 40 

Memory Pools 41 

Tasks 42 

Memory Segments 42 

Buffer Pools 43 

Exchange Objects 44 

Mailboxes 44 

Semaphores 45 

Regions 46 


Introducing the iRMX Operating System 


Contents 


5 





Ports 47 

Extension Objects and Composite Objects 48 

Object Directories, Tokens and Descriptors 49 

Nucleus Task Scheduling 50 

Priority 50 

Execution State 51 

Round-robin Scheduling 52 

Nucleus Interrupt and Exception Handling 53 

Interrupt Handlers 53 

Interrupt Handler Alone 53 

Interrupt Handler/Task Combination 54 

Exceptional Conditions 55 

Environmental and Programmer Errors 55 

Hardware Exceptions 56 

Kernel Eeatures 57 

Kernel Objects 57 

Kernel Task Management 58 

Kernel Time Management 58 

Kernel Interrupt Handling 59 

When To Use the Kernel 59 


3 BIOS and ElOS Features 

I/O System Objects, Logical Names and System Calls 61 

User Objects, Users and User Access Control 62 

Example: Multiuser System and the User Object 63 

Connections and Eile Access Modes 64 

Eile Connections 64 

Device Connections 65 

I/O Jobs 66 

Logical Names for Eiles and Devices (EIOS Only) 66 

BIOS and EIOS System Call Differences 66 

System Call Names 67 

Synchronous and Asynchronous System Calls (BIOS Only) 67 

Eiles and Directories 68 

Hierarchical Eile System 68 

Eile Access Rights 69 

Eile Types 70 

Named Eiles 70 

Remote Eiles 70 

DOS Eiles 70 

Physical Eiles 71 

Stream Eiles 71 


6 


Contents 




Devices and Device Control 72 

Device Independence 72 

File Drivers 72 

Device Drivers 73 

Loading and Configuring Drivers 73 

Device Control 74 

Fixed and Timeout Updating 74 

Disk Integrity 74 

Internal File Fragmentation 75 

Buffering with Overlapped I/O (BIOS Only) 76 

Automatic Device Reattachment (BIOS Only) 76 

Terminal Support Code 77 

System Clock 78 

Choosing Between I/O Systems 79 

BIOS 79 

BIOS 79 

Making the Decision 80 

Bxamples 81 


4 Human Interface Features 

Run-time Loading of Jobs 84 

HI Commands 85 

Human Interface System Calls 86 

Custom Command Line Parsing 87 

Multiuser Support 88 

HI Initialization 89 

System-wide Setup 89 

Logon 89 

Operator Job Creation 90 

Command Line Interpreter (CLI) 91 


5 Application Loader Features 

Dynamic Loading 94 

Loading Blat Model Applications 94 

Objects and System Calls 95 

Overlay Loading 96 


6 UDI Features 97 


Introducing the iRMX Operating System 


Contents 


7 






7 Networking Features 

Network Concepts and Terminology 99 

Network Software 100 

TCP/IP for iRMX OSs 100 

iNA 960 and iRMX-NET 101 

Network Security 102 

Networking Between Operating Systems 103 

iRMX for Windows Networking 104 

NetRDR 104 

X.25 Networking 105 

Other OS Features that Use Networking 105 


8 System Development 

Shared C Library 108 

Online Help Systems 108 

System Design 109 

A Hypothetical System Ill 

Interrupt and Event Processing 112 

Processing Commands From the Bedside Units 1 12 

Multitasking 112 

Intertask Coordination 113 

Enhancing the System 113 

Bootstrap Loading (iRMX III OS and iRMX for PCs) 114 


9 Application Debugging 

System Debug Monitor 115 

System Debugger 116 

Soft-Scope Debugger 116 


10 System Configuration 

ICU Configuration 119 

iRMX for PCs and iRMX for Windows Configuration 120 

Loadable Jobs 120 


A Related Publications 

iRMX Manual Set 121 


8 


Contents 







Glossary 

123 

Index 

141 

Service Information 

Inside Back Cover 


Figures 

1-1. Task Switching in a Multitasking Environment 13 

1-2. Multitasking and Preemptive, Priority-based Scheduling 14 

1-3. Interrupt Handler Interrupting a Task 16 

1-4. Multiprogramming 19 

1-5. Resources in a Job 20 

1-6. Object Types 21 

1-7. Object-based Solution for Message Passing 23 

1-8. Tasks Using a Semaphore for Synchronization 24 

1-9. Multitasking and Mutual Exclusion 25 

1-10. Dynamic Memory Allocation between Tasks 26 

1-11. The Layers of the iRMX Operating Systems 29 

1-12. Networked Systems 31 

1- 13. Real Mode and PV AM 32 

2- 1. Jobs in a Job Tree 39 

2-2. Tasks Using the Job's Object Directory 40 

2-3. Tasks Using Their Job's Memory Pool 41 

2-4. Tasks Using a Buffer Pool 43 

2-5. Tasks Using a Message Mailbox 44 

2-6. Tasks Using a Semaphore for Synchronization 45 

2-7. Tasks Using Ports for Communication on a Multibus II Platform 47 

2-8. Execution State Transitions for Tasks 51 

2-9. Round-robin Scheduling 52 

2- 10. The Task Execution Model 54 

3- 1. Task Creating a Eile and a User Object 62 

3-2. Tasks Sharing a Connection Object 64 

3-3. Tasks Accessing a Eile Through Connections 65 

3-4. Hierarchical Eile Structure 68 

3-5. Multiple Users with Different Access Rights 69 


Introducing the iRMX Operating System 


Contents 


9 






3-6. Tasks Using a Stream File 71 

3-7. I/O Requests from the Application Go Through BIOS and Device Drivers . 72 

5-1 . Using the Application Loader To Load a Program Dynamically 93 

5- 2. Using the Application Loader To Load a Program into a Task's Memory ... 95 

6- 1 . UDI Interface Between the Application and the Hardware 97 

7- 1 . iRMX-NET Interoperability with other OpenNet Systems 103 

8- 1. Typical Development Cycle for iRMX Applications 110 

8-2. The Hardware of the Dialysis Application System Ill 


10 


Contents 



Basic Concepts 


I Intel's family of real-time, multitasking, object-based operating systems. 


R 

M 

X 


These Real-time operating systems support applications that require 
deterministic response time, high reliability, and synchronization. 

Their Multitasking capabilities handle multiple external interrupts and 
internal events occurring asynchronously. They provide multiuser and 
multiprogramming support. 

Their executive scheduler provides preemptive, priority-based, and 
predictable response time to interrupts and events. 


Real-time applications can be; 


Measurement and 
monitoring 

Process control 


of seismic activity for analysis 
of patients in medical procedures 

of high-speed machinery or robots 
of research and lab activities 


Data acquisition and of automatic test data 

distribution to vendors or clients over networks or satellite links 


The iRMX® Operating Systems run on single-board computers and microcomputers 

built around the Intel386™, Intel486™, Pentium® and Pentium Pro microprocessors. 

There are three versions of the iRMX Operating System (OS). 

iRMX for PCs Runs on PC platforms with or without DOS, but with no 

interoperability between the OSs. It uses the PC's ROM 
BIOS to interact with peripherals. 

iRMX for Windows Runs on PC platforms concurrently with DOS; it provides 
interoperability between the iRMX OS, DOS, and 
(optionally) Windows. Provides access to off-the-shelf 
DOS software and tools and the Windows environment. 

iRMX III OS Runs on Multibus I and II platforms. Provides maximum 

configurability, including booting the OS with an 
embedded application. 
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iRMX Operating System Features 

The iRMX OS offers a broad range of real-time, object-based functions and 
features: 

• Real-time processing to monitor and control events 
— Multitasking 

— Preemptive priority-based scheduling 
— Interrupt processing 
— Predictable response time (determinism) 

— Multiprogramming 

• Objects to simplify application design and programming and to control 
resources 

— Intertask coordination and communication 
— Shared memory and dynamic memory allocation 
— System calls that manipulate objects and control the computer 
— Configurable layers of the OS, each with its own system calls 

• Example code and demonstration programs that illustrate how to use iRMX 
objects and system calls 

• Network support for file access between iRMX and other OSs 

• 32-bit architecture 

— 4 Gbyte physical addressing and 4 Gbyte segments 
— Protection features for improved reliability and multiuser support 

• Industry-standard bus support 

Real-time Processing 

Real-time processing requires these capabilities: 

• Multitasking, which means switching between threads of execution or tasks 

• Preemptive, priority -based scheduling, to determine which task needs to run 
immediately and which can wait 

• Interrupt processing, to respond to external interrupts that occur during 
processing 

• Predictable response time (determinism) so tasks execute before their deadlines 
expire 

• Multiprogramming, so more than one application can run at a time 


12 


Chapter 1 


Basic Concepts 



Multitasking 

Multitasking means the computer stops doing one task and starts doing another, as 
shown in this figure. An iRMX task is a thread of execution, similar to a UNIX 
process. 



1 . The processor is executing Task A. An event happens; a task switch occurs. 

2. The processor begins executing Task B. When Task B has finished running, Task A will 
become the running task again. 

Figure 1-1. Task Switching in a Multitasking Environment 


The iRMX OS manages task switching; it saves the old task's state (context) on the 
old task's stack and loads the new task's state before starting execution. 

Multitasking and modular programming go hand-in-hand. You start by breaking 
down a large, difficult application problem into successively smaller and simpler 
problems, grouping similar problems where you can. Finally, you solve the small 
problems in separate program modules. In the iRMX multitasking environment, 
each module is a task. 

Multitasking simplifies building an application. When you need a new function, 
you just add a new task. 

See also: Tasks, Chapter 2 in this manual; 

tasks. System Concepts 

When you combine multitasking with preemptive, priority-based scheduling, your 
application can switch from relatively unimportant tasks, to important tasks, to 
critical tasks and back again, as appropriate. 
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Preemptive, Priority-based Scheduiing 

In a preemptive, priority-based system, some tasks are more critical than others. 
Critical tasks run first and can preempt less critical tasks, as shown in this figure. 



OM02657 

1 . Task A is a low-priority task; it prints data accumulated from the robotic arm in report form. 
Task A is running, printing the latest information received from the arm. 

2. Task B is a high-priority task; it controls the robotic arm. If the arm needs moving while Task 
A is running, the print task is preempted. Task B begins running and moves the arm. 

3. After the arm is repositioned. Task A finishes printing its information. 

Figure 1-2. Multitasking and Preemptive, Priority-based Scheduling 
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Multitasking enables your application to respond to internal events and external 
interrupts, such as clock ticks from the system clock or receiver ready from a serial 
device, based on how critical they are. You determine the priority of tasks in your 
application; the iRMX OS provides the task scheduling algorithms. 

See also; Scheduling tasks, Chapter 2 in this manual; 
scheduling. System Concepts 

When you add interrupt processing to multitasking and preemptive, priority-based 
scheduling, your application can respond to interrupts as they occur. Your 
application becomes event- driven-, it does not waste time polling for interrupts. 
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Interrupt Processing 

Interrupts are signals from devices such as a malfunctioning robot or interactive 
terminal. You connect interrupt sources to the processor through Programmable 
Interrupt Controllers (PICs). 

With interrupt processing, your application can handle interrupts occurring at 
random times (asynchronously) and can handle multiple interrupts without losing 
track of the running task, or those tasks waiting to run. Interrupts can occur while 
the processor is executing either an unrelated task or a related task, as shown in the 
next figure. 
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1 . Task B is the running task; it is repositioning the robotic arm. 

2. The robotic arm malfunctions and sends an interrupt signal through the PIC. As soon as it 
receives the signal, the microprocessor stops the running task and starts an interrupt handler. 

The interrupt handler runs in the context of Task B. No new task is loaded; Task B's state 
does not need to be saved. It remains loaded in RAM until the scheduler is ready to run it 
again. Task A, the print task, is still waiting to run. 

Figure 1-3. Interrupt Handler Interrupting a Task 


Typically, you have numerous sources of interrupts in your application. Some of 
them, like the malfunctioning robotic arm, are critical; some of them are not. You 
assign interrupt levels (which map directly to priorities) to the interrupt sources by 
the order in which you connect your external sources to the PIC. The iRMX OS 
handles more critical interrupts first, and keeps track of which interrupts occurred, 
the order in which they occurred and which ones have not been handled. 
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Interrupt handlers can perform very limited operations, so you typically write an 
interrupt handler to signal an interrupt task. The interrupt task's priority is 
automatically assigned, based on the interrupt level of the external source. 

Multitasking and interrupt processing simplify expanding an application. Because 
of the one-to-one relationship between interrupts and tasks, you just add a new task 
when you need to respond to a new interrupt. Interrupt processing is also more 
efficient, since your system spends all of its time running tasks, not polling for 
interrupts. 

The Kernel offers a different model for interrupt handling. 

See also: Nucleus interrupt and exception handling. Chapter 2 in this manual; 

Kernel features. Chapter 2 in this manual; 
interrupts. System Concepts', 
interrupt_task. Driver Programming Concepts 
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Predictable Response Time 

The iRMX OS provides deterministic response; there is a predictable, worst-case 
response time to a high-priority interrupt. The OS does this in two ways: interrupt 
response time and task switch time. 

Interrupt Response Time. This is the time between a physical interrupt 
happening and the system beginning to execute the interrupt handler. A predictable 
worst-case response time to interrupt processing ensures that incoming data is 
handled before it becomes invalid. 

Task Switch Time. A task switch is saving the data registers, stack and execution 
pointers (the task state) of one task, and starting another task. Minimized task 
switch time also provides a predictable response time to a high-priority task. 

Since the typical response to an interrupt is invoking a handler and then performing 
a task switch to an interrupt task, the deterministic response time includes both the 
interrupt response and task switch times. 

Real-time response does not mean instantaneous execution. A high-priority task 
that is very long and performs many calculations will use as much processor time 
to execute on a real-time system as on any other system. The length of time 
instructions take to execute is a function of processor speed. 
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Multiprogramming 

The iRMX OS supports multiprogramming: running several unrelated applications 
on a single system, as shown in this figure. 



1 . Application A contains all the tasks relating to the robotic arm, including the print task. It may 
also contain tasks that control other devices on the factory floor. 

2. Application B contains all the tasks relating to another application that controls a chemical 
mixing system in another part of the factory. 

Figure 1-4. Multiprogramming 
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To take full advantage of multiprogramming, you provide each application with a 
separate environment; separate memory, files, and other resources. The iRMX OS 
provides this kind of isolation in a job. Typically, a job includes a group of related 
tasks and the resources they need, as shown in the next figure. 
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This job contains two tasks. 

1 . The job provides the memory the tasks need. 

2. You can catalog all of the tasks' resources in the job's object directory. 

Figure 1-5. Resources in a Job 


You decide what jobs to include in your system. The iRMX OS coordinates the use 
of resources within and between jobs so independently-developed applications do 
not cause problems for each other. 

See also: Jobs, Chapter 2 in this manual; 

jobs. System Concepts 

Multiprogramming simplifies adding new applications; you can modify your 
system by adding new jobs (or removing old ones) without affecting other jobs. In 
addition, you get more from your hardware investment by running several 
applications on it. 
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Objects and System Calls 

The iRMX OS provides basic objects and maintains the data structures that define 
these objects. The basic objects are building blocks that application programs 
manipulate. The characteristics of the objects are easy to learn and use; they are 
well-defined and consistent. 

This figure shows the iRMX-provided object types. 


Job r 


Task 


Segment 


Mailbox 




User 





Connection 


Extension 


c 






Composite 
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The icons for the object types shown in this illustration appear in all illustrations in this 
manual. 


Figure 1-6. Object Types 
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Each object type, such as a mailbox, has a specific set of attributes or 
characteristics. Once you learn the attributes of a mailbox, you know how to use 
all mailboxes. Each object also has its own set of related system calls. 

See also: Object types. Kernel objects. Chapter 2 in this manual; 

I/O system objects. Chapter 3 in this manual; 

Individual object chapters. System Concepts 

Object-based programming, which concentrates on the objects and the operations 
performed on them, is compatible with modular programming. Typically a single 
task performs only a few related functions on a few objects. 
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Intertask Coordination and Communication 


iRMX exchange objects are mailboxes, semaphores, regions, and ports. They 
enable asynchronous tasks, which run in a random order, to coordinate and 
communicate with one another by; 

• Passing messages 

• Synchronizing with each other 

• Mutually excluding each other from resources 

Messages. Tasks may need to exchange data, messages, or object tokens (object 
addresses and attributes). 

For instance, one task may accumulate input from a terminal until it receives a 
carriage return. It uses an exchange object to send the entire line of input as data to 
another task that decodes the input. 

This figure summarizes how you can solve a problem that requires routing several 
types of input into several types of output using a mailbox object. One mailbox 
and one manager task can handle messages from multiple input and output tasks. 


Input 

tasks 



Output 

tasks 


A 


B 
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1 . System calls move data from input tasks A and B to a waiting mailbox. 

2. Task C, the manager task, waits at the mailbox and determines which messages go to which 
output tasks. If another message arrives during processing, the message waits in the 
mailbox queue until the manager task can handle it. 

3. The individual output tasks receive their data at their mailboxes and process it. 

Figure 1-7. Object-based Solution for Message Passing 
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Synchronization. One task may need to run before another task. It can use an 
exchange object to signal the second task when it has completed. For example, the 
task that creates the transaction summary in an automated teller application 
shouldn't run until after the tasks that handle withdrawals and deposits have run. 
The transaction summary task must be synchronized with the other tasks. 

The iRMX OS provides several objects for synchronization that can accommodate 
a wide variety of situations. The next figure illustrates using a semaphore to send a 
signal to another task. 
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Task A is the running task. It does some preprocessing of data. Task B needs to use the 
data after Task A finishes. 

1 . Task A sends a signal (not data) to the semaphore when it finishes. 

2. Task B has been waiting at the semaphore for the signal. It begins processing the data when 
it receives the signal. 

Figure 1-8. Tasks Using a Semaphore for Synchronization 
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Mutual Exclusion. With the iRMX OS, multiple tasks can concurrently access the 
same file. This is useful in a multitasking system, such as a transaction processing 
system where a large number of operators concurrently manipulate a common 
database. 

If each terminal is driven by a distinct task, the only way to implement an efficient 
transaction system is to have the tasks share access to the database file. 
Occasionally, when tasks are running concurrently, the situation in this figure 
arises. 
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1 . Task A is the running task. It reads some data from the database and does computations 
based on the data. 

2. Task B tries to preempt Task A and update the data while Task A is working on it. Mutual 
exclusion provided by a region prevents two tasks from accessing the same data 
concurrently. 

Figure 1-9. Multitasking and Mutual Exclusion 


The iRMX OS includes regions to provide mutual exclusion. Unless Task B is 
prevented from modifying the data until after Task A has finished. Task A may 
unknowingly use some old data and some new data to produce an invalid 
computation. It should, however, read and compute the new data after Task B 
updates it. Your code can use a region to protect the data from being accessed by 
both tasks at the same time. This is called mutual exclusion. 
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Memory Pools and Memory Sharing 

Memory pools are the basis of iRMX memory management. The initial memory 
pool is all the memory available to the application (that is, free space memory). It 
is managed by the OS and allocated to the application on request. 

The initial memory pool is subdivided into smaller pools as application jobs and 
segments are created. Each job in the application has its own subpool, with a 
minimum and a maximum size. Once the minimum pool is allocated to a job, it is 
not available to other jobs. As tasks in the job create and delete objects, the job 
pool may approach its maximum size, then return to its minimum. This provides 
dynamic memory allocation of the memory pool as jobs require less memory. 

Dynamic memory allocation enables jobs to take advantage of one job freeing 
memory while another needs more. When you delete a job, its memory returns to 
the initial memory pool. 

Dynamic memory allocation is also useful within a job. All the tasks in a job 
compete for memory in the job's memory pool. Some tasks periodically need lots 
of memory to improve efficiency, for example a task that allocates large buffers to 
speed up input and output operations. These tasks can release memory for other 
tasks when they complete, as shown in this figure. 
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1 . Tasks A and B are using memory in the job's memory pool for objects they have created. 

2. Task C has completed and is deleting its objects and releasing its memory to the job's pool. 

3. Task D is requesting memory. 

Figure 1-10. Dynamic Memory Allocation between Tasks 
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Virtual Memory Allocation With the Paging Subsystem 

If you use a non-Intel compiler that produces flat model applications instead of 
segmented applications, you include the Paging Subsystem in the OS. This job 
manages the processor in paging mode, which treats memory differently from the 
segmented model used historically by iRMX applications. With paging enabled, 
flat model applications allocate virtual memory, which is indirectly accessed 
through page tables instead of in separate segments. 

Flat model applications use a different set of system calls to allocate memory than 
segmented applications. However, the job still manages a pool of memory, which 
the individual tasks can use as described above. With the Paging Subsystem, you 
can still run existing segmented applications (or write new ones) along with flat 
model applications. Flat and segmented applications must reside in different jobs. 

See also: Paging, Flat model. Programming Techniques 

paging.job, flat.job. System Configuration and Administration 


System Calls 

Each iRMX object has an associated set of system calls: programmatic interfaces 
you use to manipulate objects or control the computer's actions. System calls for 
one object type cannot manipulate objects of another type. This protects the 
objects from inappropriate modification. 

Most system calls have parameters, such as values and names, that you can set to 
tailor the call's performance. Some of the functions you can do with system calls 
are: 


create_mailbox 

set_priority 

send_message 

a_read 


Creates a new mailbox 

Sets a task's priority 

Sends a token or data to a mailbox 

Reads a data file or the contents of a directory 


Most system calls validate the parameters you enter; a condition code returned by 
the call indicates whether you used invalid parameters. There are also condition 
codes for trying to read or write segments that you do not have access to and for 
trying to write past the end of a segment. 

You can add new objects and the system calls that manipulate them to the iRMX 
OS if your application requires them. Objects and system calls you create can be 
shared by jobs. 

See also: System call summary tables in Chapter 1 of System Call Reference', 
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Operating System Layers 

The iRMX OS is a collection of layers, or subsystems. All layers have their own 
system calls. Some layers have their own objects; some use the objects from other 
layers. 

Each layer builds on the capabilities of the previous ones. These layers are all 
included in iRMX for PCs and iRMX for Windows. The Bootstrap Loader is 
included with the iRMX III OS and iRMX for PCs. 

On ICU-configurable systems, you choose which layers you need to create a 
tailored OS. These are the layers and their functions: 

iRMK Kernel A part of the Nucleus that provides high-performance task 

and time management and message passing. The Kernel 
does not provide the protection that the Nucleus does. The 
Kernel has its own objects. 

Nucleus The heart of the OS, built on the Kernel, and is the only 

required layer. It provides most of the objects that the 
other layers use. It schedules jobs and tasks, controls 
access to system resources, communicates between tasks 
and enables the system to respond to interrupts. 

Includes file and device drivers and data tables that define 
I/O devices. This layer performs I/O functions; creates and 
deletes files, and controls file access. The BIOS controls 
the Connection and User objects. 

A higher-level I/O system that provides all the BIOS 
features plus I/O buffering and overlapping, logical names 
for files and devices, and automatic reattachment of 
devices. The BIOS controls the I/O job object. 

Application Loader Loads programs from secondary storage into memory. 

(AL) 

Human Interface Provides multiuser support with logon/logoff and user job 

(HI) creation. It is the parent job for applications in iRMX for 

Windows and iRMX for PCs. It provides commands for 
controlling application systems from terminals. You can 
create additional commands for your application. 

Universal A high-level interface between the OS and the application. 

Development It enables compilers, language translators, and other 

Interface (UDI) software development tools to run. 


Basic I/O System 
(BIOS) 


Extended I/O System 
(BIOS) 
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Shared C Library 


Paging Subsystem 


Bootstrap Loader 


Provides functions and macros that enable ANSI-standard 
C programs to perform common operations concurrently. 
The Shared C Library provides support for some non-Intel 
C compilers. 

Supports flat model (non-segmented) applications by 
providing virtual memory in a flat address space; it 
manages the processor in paging mode. 

Loads the initial OS and the application's initial jobs from 
secondary storage into RAM on the hosts in the system, 
then starts the system. 


This figure illustrates the layers and the relationships between them. The UDI also 
accesses the Application Loader. 


Application 

Loader 

, , 1 . , UDI and 

Human Interface ^ 1 _ . 

C Library 

EIOS 

iRMX-NET and 
TCP/IP 

BIOS 



VM86 Dispatcher 
(iRMX for Windows and PCs) 


iRMK Kernel 

iRMX Nucleus 



iRMX is a registered trademark of intei Corporation. 


Figure 1-11. The Layers of the iRMX Operating Systems 
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Example Code and Demonstration Programs 

The /rmx386/fifemo subdirectory in the iRMX directory structure contains many 
programming examples in C, PL/M and assembler. You should use and modify the 
example code when you develop your applications. 

There are examples of: 

• Basic multitasking, creating and cataloging objects 

• Message passing 

• Interrupt handling 

• Managing terminal I/O 

• Programmatic network access 

• Third-party compiler support 

See also: Programming Techniques for an explanation of some example 

programs; 

Real-Time and Systems Programming for PCs, for additional 
programming examples 
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Network Support 

The iRMX OS software supports networking of independent computers connected 
together to exchange information. iRMX-NET enables iRMX-based computers to 
communicate with OpenNET servers and clients running other OSs, as shown in 
this figure. 



OM02660 


Figure 1-12. Networked Systems 


The basic networking software is iRMX-NET, a part of Intel's family of OpenNET 
Local Area Network (LAN) products and TCP/IP, which enables interoperability 
with most other OSs. 

In addition, iRMX for Windows can access files through standard DOS networking 
software such as Novell NetWare. 

See also; Networking, Chapter 7 in this manual; 

Network User's Guide and Reference-, 

TCP/IP and NFS for the iRMX Operating System 
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32-Bit Architecture, Addressing, and Protection 

The iRMX OS supports 4 gigabytes (Gbyte) physical addressing, 32-bit addresses 
and data types, and the addressing modes shown in this figure. 



4 Gbyte 
PVAM 


1 Mbyte 
Real Mode 
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Figure 1-13. Real Mode and PVAM 


Real mode 


Protected virtual 
address mode 
(PVAM) 


Paging mode 


Enables addressing 1 Mbyte of physical memory. Real 
mode is the initial operating or bootload mode for 
supported Intel microprocessors. During iRMX 
initialization, the microprocessor is switched into protected 
virtual address mode (PVAM). 

Enables the iRMX OS to take advantage of 32-bit 
architecture, the full 4 Gbytes of memory, and advanced 
protection features. It also enables real mode programs to 
run concurrently in Virtual 86 (VM86) mode. iRMX for 
Windows runs in protected mode, but switches to VM86 
mode to run DOS and DOS applications. 

A flat model application uses near pointers only, in a 
virtual segment that can span the entire 4 Gbyte address 
range. 
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The protection features of the microprocessor includes: 

• Memory segment length protection that prevents segment accesses from 
crossing segment boundaries. Writing too much data will not corrupt the 
system. 

• Access-rights protection that enables tasks to define access to a segment and 
prevents access to those segments in other than the defined mode. 

• When the Paging Subsystem is enabled, the processor manages memory 
through page tables. In this mode, the OS provides protection by isolating 
memory between jobs with an unallocated page table entry. An attempt to 
access beyond the allocated memory results in a processor-generated page 
fault. 

• Stack-overflow detection that prevents out-of-control tasks from overflowing 
the stack and overwriting important information. 

• Invalid-selector detection that prevents tasks from referring to segments of 
undefined memory. 

See also: Programmer's Reference Manual for your microprocessor for 

information on the internal hardware features of the microprocessor 
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Bus Architecture Support 

The iRMX OS supports these industry- standard bus architectures: PC, Multibus I, 

and Multibus II. 

PC architecture benefits and features for iRMX for PCs and iRMX for Windows 

systems include: 

• A 32-bit wide (EISA or MCA) or 16-bit wide (ISA) data word across the bus 

• A widely-installed base 

• A low-cost platform for iRMX development and target systems 

Multibus I architecture benefits and features include: 

• A 16-bit wide data word across the bus 

• A widely-installed base 

• Intelligent board-to-board communications using hardware signals and similar 
signal handling techniques 

Multibus II architecture benefits and features include: 

• A 32-bit wide data word across the bus. 

• Enhanced board-to-board communication through additional internal buses and 
a well-defined data transfer protocol. The internal buses enable virtual 
interrupt processing so any board can communicate with any other, regardless 
of hardware limitations. 

• Efficient bus use through a data packet (small portion of data) transfer scheme. 
Transferring data by packets prevents a slower device on the bus from 
monopolizing all the bus time: the bus is not limited in speed to the slowest 
device using it. 

• Support of multi-processor systems for higher performance. 
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iRMX for Windows Special Features 

DOS runs as a task under iRMX for Windows. Through iRMX for Windows, the 

iRMX OS has access to most DOS and Windows features, and DOS and Windows 

have access to most iRMX features. DOS and the iRMX OS use a small buffer in 

conventional DOS memory to exchange information. 

iRMX for Windows provides these features: 

• DOSAVindows and iRMX run at the same time on one PC-compatible system. 

• iRMX for Windows supports Microsoft Windows in standard mode. 

• DOSAVindows applications have access to iRMX objects and system calls. 
DOS applications can use many Nucleus system calls through the Real-time 
Extension (RTE) interface. Windows applications can use the RTEs through a 
DLL (Dynamic Link Library). 

• iRMX applications can use DOS and ROM BIOS commands. 

• iRMX users or applications can access named and remote DOS files through 
the Encapsulated DOS Lile Driver (EDOS). iRMX applications can send data 
to Windows applications using Dynamic Data Exchange (DDE). 

• DOS and/or Standard Mode Windows have access to memory above one 
megabyte through Extended Memory Services (XMS). 

• DOS and iRMX can share network services. 

• When standard mode Windows is running, Windows and its applications run in 
both VM86 mode in low memory and in 16-bit PVAM in extended memory. 

See also: Installation and Startup and Programming Concepts for DOS and 

Windows, for detailed information 
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iRMX for PCs Special Features 

iRMX for PCs can reside with DOS on a DOS partition, or it can reside on an 

iRMX partition. 

iRMX for PCs provides these features: 

• Uses ROM BIOS functions to control the system mass storage devices 
(diskettes and hard disks) 

• Contains a native DOS file driver and can read/write any local DOS drive 
(diskette, primary DOS partition. Extended DOS partition) without the 
presence of DOS 

• Is a cost-effective solution for many applications that don't require 
DOSAVindows interoperability or the Multibus platform 

See also: Installation and Startup 


□ □ □ 
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Nucleus and Kernel Features 


Nucleus functions include: 

• Managing objects that control access to system resources and communicate 
between tasks 

• Scheduling tasks based on priority 

• Handling interrupts based on interrupt level 
Kernel functions include: 

• Controlling Kernel objects 

• Managing tasks 

• Managing time 

Nucleus Objects 

The Nucleus provides these objects. 

• Jobs are the environments where tasks do their work. A job contains: 

— Tasks 

— Whatever objects the tasks create 
— An object directory for cataloging objects 

— A memory pool that provides memory for the tasks to do their work 

• Tasks do the work of the system and respond to interrupts and events. 

• Memory segments are addressable, contiguous blocks of memory that tasks can 
use for any purpose. 

• Buffer pools are holding areas for dynamically allocatable memory. 

• Exchange objects that tasks use to pass information are: 

— Mailboxes that enable tasks to pass messages and data 
— Semaphores that enable tasks to synchronize 

— Regions that provide mutual exclusion 
— Ports that synchronize operations and pass messages 

• Extension objects let you build new types of objects. 

• Composite objects include the extension and whatever existing objects you 
need. 
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Objects are data structures that occupy memory. Each object type has unique 
attributes, described in the next sections. Each object has a token that uniquely 
identifies it. The maximum number of objects allowed in the system at any one 
time is 8192 (2000H). 

See also: Object directories, tokens and descriptors later in this section; 

I/O system objects. Chapter 3 in this manual; 

Individual object chapters and OS extensions. System Concepts 


Jobs 


A job is an iRMX object that contains tasks and all the resources they need. iRMX 
jobs that you can create have these characteristics: 

• Jobs make up your application. 

• Jobs are passive; they cannot make system calls. 

• Jobs include one or more tasks. 

• Jobs provide resource isolation for their tasks, particularly for dynamically 
allocated memory. Two tasks of one job compete for the memory associated 
with their job. Tasks in different jobs typically do not. 

• Jobs provide error boundaries. Errors within one job do not corrupt other jobs 
or the OS because they have separate memory pools. 

• When you delete jobs, the objects associated with them also are deleted. 

You can create several kinds of jobs: 

• Dependent or child jobs are children of their parent job. 

• Loadable jobs are children of the HI. 

• First feveZ jobs (configurable in the ICU) are children of the root job. 

• I/O jobs are children of the EIOS. 

The jobs in a system form a job tree. Each job except the root job obtains its 
resources from its parent as shown in this figure. 
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application 
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1 . Initially, the root job owns all of free space memory, which is allocated as other jobs are 
created. 

2. Some of the OS layers are first level jobs, or children of the root job. Applications can also be 
first level jobs. 

3. Applications loaded at system initialization are children of the HI. In IRMX for Windows and 
IRMX for PCs, this is how you typically load applications. 

Tasks in jobs can create other jobs, enlarging the tree. 

Figure 2-1. Jobs in a Job Tree 

There are system calls to create and delete jobs, obtain information about a job's 
children, and control a job's memory pool. 

See also: Jobs, System Concepts', 

Jobs in Nucleus system call summary. Chapter 1 of System Call 
Reference 
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Object Directories 

Each job has an associated object directory. As a task creates an object, the 
Nucleus creates a token for it. A task can catalog an object, with its token and a 
corresponding name, in its own job or any other job it knows about. Typically, you 
catalog objects in the root directory if you want them accessible from several other 
tasks. Other tasks that know the name can use the object directory to look up and 
access the object, as shown in this figure. 
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1 . Task A catalogs an object in its own job's object directory. 

2. Task B looks up the object, such as a mailbox, in the object directory in order to use it. Now, 
Task A can send a message to the mailbox and Task B can receive it. 

Figure 2-2. Tasks Using the Job's Object Directory 

Objects that are cataloged can also be shared across job boundaries. 

See also: Object directories, tokens and descriptors in this chapter 
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Memory Pools 

Each job has an associated memory pool. This is an amount of memory, with a 
specified minimum and maximum, that is allocated to the job and its children. The 
minimum memory is always contiguous. Usually, all memory needed for tasks to 
create objects in the job comes from the job's memory pool, as shown in this figure. 
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Tasks A and B obtain memory from the job's memory pool. 

Figure 2-3. Tasks Using Their Job's Memory Pool 

If there is not enough contiguous memory currently available (up to the maximum 
size of the job's memory pool), the OS tries to borrow from the job's parent, and on 
up the job tree if necessary. In general, you should allocate enough memory so that 
jobs do not need to borrow memory or create additional segments, since both of 
these require additional time. 

In the iRMX III OS, you can also statically allocate memory to jobs. But once the 
memory is allocated, it cannot be freed for other jobs. The total memory 
requirement of the system is always the sum of the memory requirements of each 
job. Static memory allocation uses more memory than dynamic allocation, but 
may be safer. 

See also: Memory pools. System Concepts', 

Segments and memory pools in Nucleus system call summary. 

Chapter 1 of System Call Reference 
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Tasks 


Tasks are the threads of execution or active, code-executing objects in a system. 

Tasks typically respond to external interrupts or internal events. An external 
interrupt can be a keystroke or a system clock tick; an internal event can be the 
arrival of a message at a mailbox. Tasks have both a priority and an execution 
state (whether the task is running or not). 

There are system calls to create tasks and delete tasks, view and manipulate a task's 
priority, control task readiness, and obtain task tokens. 

See also: Nucleus interrupts, events and exceptions, in this chapter; 

tasks. System Concepts', 

tasks in Nucleus system call summary. Chapter 1 of System Call 
Reference 

Memory Segments 

Segments provide memory for tasks to use for many purposes, including 
communicating and storing data. A task requests a segment of whatever size it 
needs. The segment is usually allocated from the memory pool of the task's job, as 
shown in Figure 2-3. If there is not enough memory available (up to the maximum 
size of the job's memory pool), the Nucleus tries to borrow from the job's parent, 
and on up the job tree if necessary. 

There are system calls to request a memory segment of a certain size, delete a 
segment, and find out the size in bytes of a segment. 

See also: Segments, System Concepts', 

segments and memory pools in Nucleus system call summary. 

Chapter 1 of System Call Reference 
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Buffer Pools 


Buffer pools also provide memory for tasks. A buffer pool is a set of existing 
memory segments that you can dynamically allocate. 

Tasks request buffers, use them, and then release them back to the buffer pool, 
which manages them, as shown in this figure. Using a buffer pool cuts down on 
system overhead because allocating existing buffers is faster than creating and 
deleting memory segments. 
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1 . Tasks A and B are using buffers in the buffer pool. 

2. Task C is releasing its buffer. The buffer can be reallocated to another task. 

Figure 2-4. Tasks Using a Buffer Pool 

There are system calls to create a buffer pool, fill it with buffers, view the attributes 
of a buffer pool, and delete it. 

See also; Buffer pools. System Concepts', 

buffer pools in Nucleus system call summary. Chapter 1 of System 
Call Reference 
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Exchange Objects 

The four Nucleus exchange objects are mailboxes, semaphores, regions, and ports. 

Mailboxes 

Mailboxes provide intertask communication between tasks in the same job or in 
different jobs. They can send information and, since a task may have to wait for 
information before executing, they can synchronize task execution. There are two 
types of mailboxes: 

Message mailboxes Send and receive object tokens. 

Data mailboxes Send and receive data. 

This figure shows how tasks use a message mailbox to send a token for a segment. 



1 . Task A creates a segment and puts data into the segment. 

2. Task A sends the segment token to a mailbox. 

3. Task B waits to receive the segment token at the mailbox. You can specify whether or not 
Task B should wait if the token isn't in the mailbox. 

4. Task B obtains the token and receives the data in the segment. 

Figure 2-5. Tasks Using a Message Mailbox 


Mailboxes have task queues, where tasks wait for messages, and message queues, 
where messages wait to be given to tasks. The task queue may be FIFO- or 
priority-based; the message queue is FIFO-based. 

You use the same system calls to create and delete message and data mailboxes. 
However, you use different calls to send and receive messages or data. 

See also: Mailboxes, System Concepts', 

Mailboxes in Nucleus system call summary. Chapter 1 of System Call 
Reference 
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Semaphores 

Tasks use semaphores for synchronization. 

A semaphore is a counter that takes positive integer values. Tasks send units to and 
receive units from the semaphore. When a task sends n units to a semaphore, the 
value of the counter is increased by n; when a task receives n units from a 
semaphore, the value of the counter is decreased by n. 

This illustration shows a typical example of a binary (one-unit) semaphore used for 
synchronization. 



1 . Task A needs to do some work before Task B starts running. Task A creates a semaphore 
with one unit. To enable synchronization, Tasks A and B should request and obtain the unit 
before running. 

Task A obtains the unit. Because the semaphore has no units, Task B cannot run. 

2. When Task A completes, it returns the unit to the semaphore. Task B can now obtain the unit 
and begin running. 

Figure 2-6. Tasks Using a Semaphore for Synchronization 

Semaphores enable synchronization; they don't enforce it. If tasks do not request 
and obtain units from the semaphore before running, synchronization is not 
achieved. Each task must send a unit back to the semaphore when it is no longer 
needed. Otherwise, tasks can be permanently prevented from running. 

Semaphores can also provide mutual exclusion from data or a resource like this: 

1. Task A requests one unit from a binary semaphore, and uses the resource when 
it receives the unit. 

2. Task B requests one unit from the semaphore before using the resource. Task 
B must wait at the semaphore until Task A returns the unit. 

Semaphores enable mutual exclusion; they do not enforce it. 
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Semaphores have a queue where tasks wait for units. The queue may be FIFO- or 
priority-based. There are system calls to create and delete semaphores, and to send 
and receive units. 

See also: Semaphores, System Concepts', 

Semaphores in Nucleus system call summary. Chapter 1 of System 
Call Reference 


Regions 

A region is a binary semaphore with special suspension, deletion, and priority- 
adjustment features. Regions provide mutual exclusion from resources or data; 
only one task may control a region at a time; only the task in control of the region 
can access the resource or data. Once a task gains control of a region, the task 
cannot be suspended or deleted until it gives up control of the region. When the 
running task no longer needs access, it exits the region, which enables a waiting 
task to access the resource or data. 

Regions can have a priority queue, which you should use. Then, if a higher- 
priority task tries to enter a busy region, the priority of the task in the region is 
raised temporarily so that it equals the waiting task's priority. This helps prevent 
priority-inversion, as shown in this example: 

1. Task A is the running task. It is a low-priority task with control of a region, 
accessing some data. The region has a priority queue. The only other task that 
uses the data is Task C, a high-priority task that is not ready to run. 

2. Task B, a medium-priority task, becomes ready to run and preempts A. 

3. Task C becomes ready to run and preempts B. It runs until it tries to gain 
control of the region. Task A's priority is raised to equal Task C's priority until 
Task A releases the region; then its priority returns to its initial level. 

4. When Task A releases the region. Task C receives control of the region and 
uses the data. When Task C completes. Task B runs. 

Without a high-priority queue. Task B would have preempted A while A had 
control of the region; C would have preempted B, but would have been unable to 
use the data because A had control of the region. 

Regions require careful programming to avoid deadlock, where two tasks need 
access to two resources protected by regions at the same time and one task has 
control of one region while the other task has control of the other region. 

Regions have a task queue where tasks wait for control. The queue can be FIFO- 
or priority-based. There are system calls to create, control, and delete regions. 

See also: Regions, System Concepts', 

Regions in Nucleus system call summary. Chapter 1 of System Call 
Reference 
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Ports 


Ports have two uses: 

• Message-passing on all platforms 

• Signal passing to synchronize Multibus II operations 

On all platforms, you can use message ports for short-circuit message passing. 

Ports enable efficient communication between tasks on the same host, in the same 
or different jobs: a message is copied from the source buffer in the sending task to 
the destination buffer in the receiving task. You use buffer pools to provide fast 
storage allocation for messages received at ports. 

On Multibus II systems, you can use ports between host boards in the system, 
including hosts that are not running an iRMX OS. Each port is an access point into 
the bus, through which you can send or receive messages or send signals. 

This figure shows communication between tasks on different hosts in a Multibus II 
platform. Tasks on different hosts must each have access to a port. Each port must 
have a socket identifier: a combination of the port and host IDs. 



1. Task A is the sending task. It sends the message to a port on its host. The message travels 
on the bus. 

2. Task B is the receiving task. It receives the message at a port on its host. 

Figure 2-7. Tasks Using Ports for Communication on a Multibus II Platform 


Ports provide more functionality and require more programming effort than 
mailboxes. There are system calls to create, attach, manipulate, detach, and delete 
ports. There are several system calls to send, receive, and cancel messages. 

See also: Ports, System Concepts', 

Communication service calls in Nucleus system call summary. 
Chapter 1 of System Call Reference 
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Extension Objects and Composite Objects 

If your system requires an object type that is not supplied by the iRMX OS, you 
can add a new object type by extending the iRMX OS. A new object type is an 
extension object. Each new extension object type requires its own OS extension. 

Each new extension object type must be manipulated by its own system calls; these 
calls should not be used for other object types. There can be numerous objects of 
the given type and they must have the same form and function within the type. 

An OS extension that you write for an extension object type is called a type 
manager. Each extension object type requires its own type manager that must 
provide system calls to: 

• Create objects of the new type 

• Manipulate the objects as required 

• Delete the objects 

You can write OS extensions to add utilities to the OS or to provide some 
additional functionality. Eor example, in designing a system to control heat-saving 
blinds in a greenhouse, you might need a data structure that includes information 
from a photo-sensitive cell measuring the sunlight falling on the greenhouse, and 
from a thermostat reading the temperature. The application could use this data to 
control when to open or close the blinds. This data structure is an extension object. 
The system calls that read or write its contents are part of the type manager. 

There are system calls to create and delete an OS extension. 

See also: Type managers, extension objects, operating system extensions. 

System Concepts', 

extension objects in Nucleus system call summary. Chapter 1 of 
System Call Reference 

Individual objects that you create from the extension object type are composite 
objects. Composite objects are collections of existing objects (ports, buffer pools, 
etc.); the OS treats the result as a single object. 

There are system calls to create, manipulate, and delete composite objects. 

See also: Composite objects, call gates System Concepts', 

Composite objects in Nucleus system call summary. Chapter 1 of 
System Call Reference', 

VO (view object) command in System Debugger Reference for 
information on composite objects 
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Object Directories, Tokens and Descriptors 

The Nucleus manages objects using: 

• The object directory of each job 

• The token for each object, a 16-bit selector or handle for the object 

• A descriptor that defines the physical address and attributes of the object 

The OS assigns each object a descriptor when it is created. Descriptors contain an 
object's attributes, such as its size and access type. 


All descriptors reside in descriptor tables used by the processor. There are three 
types of descriptor tables: 

Global Descriptor Contains up to 8K of descriptors. Each descriptor 

Table (GDT) contains the physical address used by the system to access 

an area of memory. Every task in the system uses 
descriptors in the GDT. There is only one GDT for the 
entire OS. 


Local Descriptor Are reserved for system use. 
Tables (LDTs) 


Interrupt Descriptor Contains the addresses of up to 256 handlers to execute 
Table (IDT) when events occur. Addresses are entered automatically 

into the IDT when the system is created and you can enter 
them dynamically using a system call. 


Call gates are special descriptors in the Global Descriptor Table. They enable 
entry into the iRMX OS and OS extensions, and are established when the system is 
configured. They redirect flow within a task. Each system call, including those 
you write, uses a call gate to transfer control to the iRMX system call routine 
requested. 

See also: Tokens, descriptor tables. System Concepts', 

Descriptors in Nucleus system call summary. Chapter 1 of System 
Call Reference', 

Reference manual for your microprocessor for more details 
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Nucleus Task Scheduling 

The Nucleus switches between tasks and makes sure the processor is always 
executing the appropriate task. The Nucleus maintains an execution state and a 
priority for each task. 

Priority 

The priority is an integer value from 0 through 255, with 0 being the highest 
priority. 

Range Usage 

0-16 Used by the OS for hardware exceptions. Cannot be masked. 

56- 127 Used by the OS for servicing external interrupts. Creating a task that 

handles internal events here masks external interrupts numerically higher. 

128- 130 Use for tasks that communicate with interrupt tasks. 

131-255 Use for tasks that handle internal events, such as message passing. You 
can usually start using round-robin scheduling at about 200. 

See also: Round-robin scheduling and Nucleus Interrupt and Exception 

Handling in this chapter 

Interrupt tasks mask numerically higher levels. When you assign interrupt levels, 
give a numerically lower level to interrupts that can't wait, such as serial input, and 
a higher level to interrupts that can wait, such as cached input. 
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Execution State 


The execution state for each task is, at any given time, either running, ready, 
asleep, suspended, or asleep-suspended. 

Tasks run when they have the highest (numerically lowest) priority of all ready 
tasks in the system and are ready to run. Tasks can change execution state, as 
shown in this figure. 
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1 . Tasks are created in the ready state. 

2. The running task is the ready task with the highest priority. It runs until it is preempted by a 
higher priority task that is ready or until it removes itself from the ready state. 

3. A task in any state except ready cannot run, even if it has the highest priority. 

Figure 2-8. Execution State Transitions for Tasks 

A task can put itself to sleep or suspend itself directly by using system calls for that 
purpose. A task might indirectly be put to sleep by the Nucleus if it makes a 
“blocking” call; for example, by waiting at a mailbox until a message arrives. The 
Nucleus puts the task in the ready state when the message arrives. 
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Round-robin Scheduling 

The iRMX OS also provides round-robin scheduling, where equal-priority tasks 
take turns running. Each task gets a time slice, an equal portion of the processor's 
time. If a task has not finished running when its time slice expires, it goes to the 
end of a circular queue where it waits until all tasks ahead of it have used up their 
time slices, as shown in this figure. You adjust the length of the time slice and set 
the priority level where round-robin scheduling occurs. 


© ® 



1. Task D is the running task. When its time slice expires, its state will be saved. In round-robin 
scheduling, tasks stop running when their time slice runs out. 

2. Task F is the ready task. When Task D's time slice expires, Task F will be the running task. 

3. When the time slice of running Task D expires, it moves to the end of the queue. 

Figure 2-9. Round-robin Scheduling 

Of course, a higher priority task will still preempt any running task in the round- 
robin queue, regardless of the amount of time left in its time slice. 

Round-robin scheduling cannot guarantee a predictable worst-case response to 
events because the number of events in the queue varies. 

See also: Task priorities. System Concepts 
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Nucleus Interrupt and Exception Handling 

Interrupts and exceptional conditions have special handlers. The Kernel provides 
additional interrupt handling capability. 

See also; Kernel Features in this chapter 

Interrupt Handlers 

System hardware invokes an interrupt handler to respond to an asynchronous 
interrupt from an external source, based on its entry number in the IDT. The 
handler takes control immediately and saves the register contents of the running 
task so it can be restarted later. There are two ways you can service the interrupt: 

• Using a handler alone 

• Using a handler/task combination 

Interrupt Handler Alone 

The interrupt handler alone can process only interrupts requiring very little 
processing and time. Handlers without tasks can do these activities: 

• Accumulate data from the device in a buffer. The data must have an 
associated task to be accessed and used. 

• Disable levels. A handler should only disable levels for a very short time and 
under special circumstances. For example, a device driver procedure may 
need this call to prevent interrupts when resources needed by the driver are 
being deleted. Numerically higher levels are disabled anyway. 

• Find out what level is currently being serviced. This is useful if one handler 
services several interrupt levels. 

• Send an EOI signal to the hardware. 

By itself, an interrupt handler can only do very simple processing, such as sending 
an output instruction to a hardware port to cause a light to blink, indicating the 
device is functioning. Handlers can use only a few system calls. 

During the time the interrupt handler is executing, all other interrupts are disabled. 
Since even very high level interrupts are disabled, it is essential that the handler 
execute quickly and exit. 

When the handler finishes servicing the interrupt, it sends an EOI to the PIC, 
restores the register contents of the interrupted task, and surrenders the processor. 
The processor returns to the interrupted task. 
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Interrupt Handler/Task Combination 

An interrupt handler/task combination is much more flexible. The handler may do 
a small amount of processing, but it typically signals its corresponding interrupt 
task to do most or all of the rest of the interrupt processing. You need to use an 
interrupt handler/task combination if the processing requires a lot of time or 
requires system calls that interrupt handlers cannot use. 

When there is a specified interrupt task, the handler can put the information it 
accumulates into a segment, if one has been set up by the interrupt task. The 
interrupt task can access the data in the segment and do whatever is required. 

Interrupt tasks have access to the same resources and can use the same system calls 
as ordinary tasks. The only difference is that interrupt tasks have an interrupt level 
assigned by the OS, based on the level of the handler. Ordinary tasks have a 
priority which you assign. 

In addition to the usual task activities, an interrupt task can also: 

• Cancel an assignment of an interrupt handler to an interrupt level 

• Wait for an interrupt to occur 

• Enable and disable interrupts 

This illustration shows how an interrupt task enters an event loop while it waits to 
service an interrupt. 
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1 . The interrupt task initializes when the system starts and begins waiting for a signal when an 
interrupt occurs. 

2. When signaled, the interrupt task executes the required operations. 

3. The interrupt task releases control by waiting for a signal to process the next interrupt. 

Figure 2-10. The Task Execution Model 
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See also: Init_IO procedure and interrupt task, Appendix A in Driver 

Programming Concepts for interrupts in random access devices; 
inthand and inttask examples under the /rmx386/demo subdirectory 
for a demonstration of an interrupt handler and task 

Exceptional Conditions 

These are sources of exceptions: 

• Environmental errors, such as trying to write to a printer that is offline 

• Programmer errors, such as making a mistake in a system call 

• Hardware exceptions, such as trying to execute a read/write data segment 

Environmental and Programmer Errors 

The Nucleus does validity testing and condition checking within system calls. It 
generates a condition code whenever it detects an exceptional condition (an error or 
something unusual), as well as when a call completes successfully. For successful 
completion, system calls return OOOOH, or the mnemonic E_OK. For a failure, the 
code indicates what prevented successful completion. For example, 0002H or 
E_MEM returns if there is not enough memory to complete the call. 

There are two ways to handle exceptional conditions: 

• Using an exception handler 

• Processing exceptions in the task that issues the system call (inline processing) 

Using an exception handler simplifies error processing. When an error occurs, 
control transfers to the task's exception handler. The exception handler can be: 

• The exception handler you write and specify for the task 

• The exception handler you write and specify for the job 

• An default exception handler provided with the OS 

Each exception handler has a mode, which indicates when it is called: 

• Never, meaning tasks handle all exceptions inline 

• On programmer errors, but all other exceptions are handled inline 

• On environmental errors, but all other exceptions are handled inline 

• Always 
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Exception handlers typically use one of these methods: 

• Correct the cause of the problem and try again. 

• Log the error and continue. 

• Delete or suspend the job that caused the error. (The default Intel handler 
deletes the job; there are also other supplied handlers.) 

The alternative to exception handlers is inline processing. This enables you to 
provide special processing for unusual circumstances within a task. 

Hardware Exceptions 

An error that occurs as a result of a hardware exception also causes an exceptional 
condition. Hardware exceptions result from conditions like dividing by 0, or when 
a protected mode program tries to access or execute out of a memory segment 
bounds or tries to execute a read/write data segment. 

If you do not designate an exception handler for hardware exceptions, they can 
cause your application to be caught in an infinite loop or be terminated. You can 
create exception handlers that process hardware exceptions. 

iS> Note 

Prior to release 2.2 of the OS, hardware exceptions were not 
returned to exception handlers. However, exception handlers 
now can receive any hardware exceptions, along with other 
exceptions. You must rewrite older exception handlers so that 
they can deal with the possibility of receiving a hardware 
exception. 

See also: Exception Handling, hardware exceptions. System Concepts', 

Exception handlers in Nucleus system call summary. 

Chapter 1 of System Call Reference', 

Condition Code list. System Call Reference 
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Kernel Features 


The Kernel provides a set of objects and system calls; some are similar to those in 
the Nucleus and some are entirely different. Kernel system calls provide 
functionality beyond that of the Nucleus. In most cases, these calls provide higher 
performance compared to the equivalent Nucleus calls. 

The Kernel provides interface libraries for PL/M, C, and FORTRAN that enable 
you to use the same data types for any of these languages. The assembly language 
interface is a register interface that requires additional programming effort. 

The Kernel system calls enable you to use these Kernel features: 

• Kernel objects 

• Kernel task management 

• Kernel time management 

The Kernel also has more system calls available for interrupt handlers than the 
Nucleus. 

Kernel Objects 

The Kernel provides these objects: 

• Software alarms (virtual timers) that invoke alarm handlers you write. Alarm 
handlers operate in similar fashion to iRMX interrupt handlers. 

• Semaphores for synchronization and mutual exclusion. There are three kinds 
of Kernel semaphores: FIFO queue, priority-based queue, and Region 
semaphores. The region semaphore provides priority adjustment like the 
Nucleus Region. 

• Mailboxes for communication between tasks. Mailboxes have task and 
message queues. The task queues can be FIFO- or priority-based; the message 
queue is always FIFO, like the Nucleus. 

• Memory pools and areas. A Kernel memory pool always spans a contiguous 
range of memory. You can create a Kernel memory pool in a specific range. 
Tasks share a memory pool for dynamic memory allocation by checking out, 
using, and returning memory areas in the memory pool. The memory manager 
keeps track of which areas in the pool are currently in use and which are 
available. It does not protect an area from unauthorized access and deletion. 

Kernel memory pools and areas you allocate are created from iRMX segments; 
make sure your jobs have enough memory to handle Kernel requirements. 
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You must allocate memory for Kernel objects and may allocate memory beyond 
the Kernel's needs. This is different from iRMX objects, where memory is 
allocated from the job's pool automatically. You can use this additional memory to 
store application-specific state information associated with the object. When you 
create an object, the Kernel returns a token that identifies that object. 

See also: Kernel objects. System Concepts', 

Kernel system call summary. Chapter 1 of System Call Reference 

Kernel Task Management 

The Kernel enables you to: 

• Control task switching using scheduling locks 

• Add task handlers to supply additional OS functions 

A running task can use a scheduling lock to protect itself from being preempted in 
some cases. In those cases, a task switch will not occur until the task releases the 
lock, even if a higher priority task is ready to run. 

Task handlers you write execute when you are creating a task, deleting a task, or 
switching to another task. Possible functions that task handlers may include are 
saving and restoring the state of coprocessor registers on a task switch, masking 
interrupts based on task priority, or implementing statistical and diagnostic 
monitors. 

For example, you can use the task switch handler to determine which tasks in your 
system execute most frequently. 

See also: Kernel task management. System Concepts 

Kernel Time Management 

The Kernel enables tasks to: 

• Create single-shot alarms and repetitive alarms for a specified time interval 
and specify which alarm handler to invoke. 

• Specify a clock tick granularity of less than the 10 millisecond granularity 
provided by the Nucleus. 

See also: Kernel time management. System Concepts 
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Kernel Interrupt Handling 

Unlike the Nucleus, the Kernel provides many system calls that you can use in 
interrupt handlers. For example, you can create Kernel semaphores or mailboxes in 
an ordinary task, then use Kernel calls to send units or messages from the interrupt 
handler to the ordinary tasks, which execute based on their priority, not on an 
interrupt level. Ordinary tasks do not mask interrupts; interrupt tasks do. 


When To Use the Kernel 

Use the Kernel in these situations: 

• Only for very well-tested code 

• For isolated parts of the application, such as signaling ordinary tasks from an 
interrupt handler 

• When performance is critical, such as high-performance, unvalidated sending 
and receiving of data mailbox messages and semaphore units 

It is a good idea to write, test and debug your application using Nucleus system 
calls. When the application is correct, substitute Kernel system calls where 
appropriate. 

The Kernel does not provide the protection and validation features available in the 
Nucleus: 

• Kernel system calls do not validate parameters. Use Nucleus system calls 
instead, if you need parameter validation. 

• The Kernel assumes that all memory reference pointers it receives are valid. 

• Kernel objects are not protected against unexpected deletion. 

• The Kernel uses the flat, 4 Gbyte addressing capabilities of the microprocessor. 
It does not use segmentation. 

Since the Kernel does not provide a protected and validated environment, it is more 
difficult to debug. 

See also: Kernel data types. Kernel system calls and handlers. System Call 

Reference-, 

Kernel, assembly language interfaces to the Kernel, System Concepts 
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BIOS and BIOS Features 


Several iRMX OS layers provide I/O operations: the Basic I/O System (BIOS), the 
Extended I/O System (BIOS), the Universal Development Interface (UDI), and the 
Shared C Library. Each provides a different level of support and unique features. 
The BIOS, UDI and Shared C Library use the BIOS in most cases. 

See also: UDI, Chapter 6 in this manual; 

Shared C library. Chapter 8 

I/O System Objects, Logical Names and System 
Calls 

These are the I/O objects that provide access control and I/O capability: 

• User objects are lists of user IDs. 

• Connection objects are the bonds between a file or device and a task. 

• I/O Jobs are similar to Nucleus jobs, but provide the environment for BIOS 
system calls. 

There are BIOS, BIOS, and UDI system calls to create, delete, and manipulate I/O 
objects. 
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User Objects, Users and User Access Control 

People access files through tasks; user tasks are tasks requesting access to files. 
The user object can prevent an unauthorized task from accessing a file. User 
objects provide user access control by verifying users, as shown in this figure. 
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1 . Task A creates a file. Task A is the owner of that file. Task A's user ID is listed first in the 
file's access list. 

2. Task A also creates a user object. Task A's user ID is listed first in the user object. Task A 
lists user IDs for other tasks that can access the file in the user object. 

Only tasks listed in the user object can access the file. 

Figure 3-1. Task Creating a File and a User Object 


You specify users when you use the BIOS to create a file. The BIOS, UDI and 
Shared C Library use the default user object, which applies to all tasks in the job. 
For iRMX for Windows and iRMX for PCs, the DOS file system does not support 
users other than World. 

See also: File access rights, later in this chapter 

There are BIOS calls to list IDs in user objects and create and delete user objects. 
There are BIOS calls to list ID's associated with a user and to verify users. A user 
may have more than one user ID. 

See also: User system calls, BIOS, and BIOS system call summary tables in 

Chapter 1 , System Call Reference 
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Example: Multiuser System and the User Object 

Suppose that several departments share a computer. An individual in one 

department may: 

• Allow only herself to delete her files. She specifies this when she creates the 
files. 

• Allow people within her department to write and read the files. She specifies 
this when she creates the user object for her department members. 

• Allow people in other departments to only read the files. She specifies this 
when she creates the user object for other departments. 

In systems where each user has a password, user access control can also be set up 

on an individual basis. 
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Connections and File Access Modes 


There are connections for files and connections for devices. 

File Connections 

A file connection object is the bond between a file and a task. Connections provide 
file access mode control based on the operation performed on the file, as shown in 
this figure. The connection object can prevent a task from modifying or deleting a 
file inappropriately. 



1 . Task A creates a connection to a file and opens it. Task A specifies that this connection is for 
reading only and this file can be shared by other readers only. 

2. Task B wants to read the file so it can share the connection A created. 

3. Task C wants to write the file. It cannot use this connection for writing. Since the share 
mode is share with readers, Task C cannot obtain a connection to the file until Task A deletes 
its connection. 

Figure 3-2. Tasks Sharing a Connection Object 


Whenever you create a file, the I/O system returns a connection. 

Connections contain the file access modes to the file. You specify file access 
modes once, when you create the connection, rather than each time you open the 
file. 
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The file access modes specified in connections are: 

Mode Meaning 

Private use Share with no one 

Open for reads Share with readers 

Open for writes Share with writers 

Open for reads/writes Share with readers/writers 

If the first connection to a file enables sharing, several file connections can 
simultaneously exist for the same file; several tasks can concurrently access 
different locations in the file. Each connection maintains a pointer to the location 
within the file where the task is reading or writing, as shown in this figure. 
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Figure 3-3. Tasks Accessing a File Through Connections 

File connections cannot be shared across jobs. 

There are BIOS, BIOS, and UDI system calls to create, open, close and delete file 
connections. 

See also: Files and Connections in BIOS, BIOS and UDI system call 

summaries. Chapter 1 of System Call Reference 

Device Connections 

A device connection is the bond between the task and the device. You must attach 
a device before you can use it for I/O operations. 

Device connections can be shared across jobs. 

See also: Device connections. System Concepts 
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I/O Jobs 


An 1/0 job provides resources for tasks that perform I/O using BIOS system calls. 

If a task is not in an I/O job, it cannot successfully use all of the BIOS system calls. 
I/O jobs are very similar to ordinary jobs. 

If you use C Bibrary calls, they must be made from I/O jobs. 

There are BIOS calls to create, delete, and start I/O jobs. 

See also: I/O jobs in BIOS, BIOS and UDI system call summaries. Chapter 1 of 

System Call Reference 

Logical Names for Files and Devices (ElOS Only) 

The BIOS enables you to use logical names to refer to files and devices. A logical 
name is a string of characters that identifies a file, directory, device, or remote 
computer system. You can substitute a logical name for a long pathname, and use 
it in several tasks or jobs. 

The iRMX OS uses the logical name :config: for the file /rmx386/config, for 
example. 

If the pathname changes, you redefine the logical name; you don't need to change it 
everywhere. The BIOS associates each logical name with a particular file 
connection or device connection. 

You can make a logical name available to one job, to a group of jobs, or to all jobs 
in the system by cataloging the name in the local job's object directory, the global 
job's object directory, or the root job's object directory, respectively. 

See also: Bogical names in BIOS system call summary. Chapter 1 of System 

Call Reference', 

object directories. Command Reference 

BIOS and ElOS System Call Differences 

There are several differences between system calls in the BIOS and the BIOS. 
System call prefixes or names may be slightly different, reflecting functional and 
compatibility differences. The BIOS has two types of system calls: synchronous 
and asynchronous. The BIOS has only synchronous calls. The BIOS calls 
generally have more parameters than the BIOS calls, giving greater control and 
flexibility to the BIOS and more simplicity to the BIOS. 
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System Call Names 

Many BIOS and BIOS system call names are identical except for the prefixes: 

rq (16-bit address, 1 Mbyte memory pool) rqe (32-bit address, 4 Gbyte pool) 
rq_a (asynchronous) rq_s (synchronous) 

For example, the rq_create_iojob system call operates on all iRMX OSs and is 
available for compatibility between iRMX I, II, and III. The rqe_create_iojob 
system call supports the extended features of the Intel386 and later 
microprocessors, such as memory pools greater than 1 Mbyte. Unless 
compatibility with iRMX I systems is an issue, use the system calls with the rqe 
prefix instead of the ones with the rq prefix. 

The BIOS asynchronous rq_a_create_file and rq_a_close system calls perform 
analogous functions to the BIOS synchronous rq_s_create_file and rq_s_close 
calls. 

Synchronous and Asynchronous System Calls (BIOS Only) 

These are the two types of BIOS calls: 

Synchronous calls Begin running as soon as your application invokes them, 
continue running until they finish their tasks or detect an 
error, then return control to your application. The call names 
begin with rq_. 

Asynchronous calls Run concurrently with your application, which can continue 
running while the BIOS deals with devices such as disk 
drives and tape drives. The call names begin with rq_a. 

This example shows the difference between synchronous and asynchronous 
operations: 

1. Task A and Task B need to read a file. Task A makes an asynchronous call 
and Task B makes a synchronous call. 

2. The parameters for both calls are checked for validity. 

3. Task A continues executing application code, doing computations perhaps, 
until notified that the data has transferred. Task B waits for the data transfer to 
complete before continuing. 

If you make an asynchronous call, you use a mailbox to notify the task when the 
call has completed. Asynchronous calls do require more programming effort. 
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Files and Directories 

The iRMX I/O Systems provide support for: 

• Hierarchical file systems 

• File access rights to protect files 

• Distinct file types 

• System calls to create, delete, read, write, and manipulate files 

Hierarchical File System 

The iRMX OS uses a hierarchical filenaming system (similar to UNIX and DOS). 
Your directory and file names can reflect relationships between files and you can 
assign a unique pathname to each file. 

With an unlimited hierarchical file system, you can add directories when you need 
them, as shown in this figure. 
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1 . You can create a new directory whenever you need to, such as for a new department 
member. 

2. The owner of the new directory can use it to provide unique pathnames to any number of 
subdirectories and files. 

Figure 3-4. Hierarchical File Structure 


iRMX filenames can be 14 characters long, and can include more than one . (dot). 
iRMX is case-insensitive. 

The iRMX OS treats directories like files; entries in a directory are just filenames. 
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File Access Rights 

The iRMX access rights for files are read, append, update, and delete; for 
directories they are list, add, change, and delete. Access rights are maintained on a 
per-file basis in a file access list. The iRMX OS supports multiple users with 
different file access rights as shown in this figure. 


© 

© 

1 . User A is the owner of the file. This user can read, append to, update, or delete the data 
file C. 

2. User B can read, append to, and update the same file. 

3. The World user (not shown) can only read the file. 

Figure 3-5. Multiple Users with Different Access Rights 


A 

R/A/U/D 

B 

R/A/U 

WORLD R 
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The DOS file system does not support users other than World, and file access rights 
are limited to two options: read-only and read/write/change. For iRMX for 
Windows systems, iRMX users and tasks can change their DOS file access to 
correspond to the DOS read-only and read/write/change attributes. DOS directories 
cannot be made read-only. 

File access rights and owner IDs can undergo translation between remote files on a 
network that uses the Network File System (NFS). The specific translations used 
depend on the operating systems and users involved. 

See also: File access. Command Reference 

Accessing NFS Files, TCP/IP and NFS for the iRMX Operating 
System 
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File Types 

These are the types of files: named, remote, DOS, physical, and stream. The same 
system calls work with any file type, providing/iZe independence. For example, 
you use the same system call to open a named file as you do to open a stream file. 
This enables you to create tasks and applications that you can readily switch from 
one file type to another. 

Named Files 

Named files are for local random-access, secondary-storage devices, such as disk 
drives and diskette drives. Named files have a hierarchical structure that reflects 
the relationships between the files and the application; you can store many named 
files on one device. Named files provide access control because they have 
associated user and connection objects. The native iRMX file format is maintained 
by the Named File Driver. 

With file independence, you can use named files during development and 
debugging, even though tasks will ultimately use other file types. For example, 
your application might need two tasks that communicate by using a stream file. 
You might implement the writing task before you implement the reading task. For 
the purpose of debugging the writing task, you could use a named file on a disk in 
order to examine the information being written. Later, after you implement the 
reading task, you can route the information to the stream file rather than the disk. 

Remote Files 

A remote file is a file located on another computer connected by a network. The 
I/O systems access remote files through networking software, including files on 
systems running an OS other than the iRMX OS. You can access remote files 
using the NFS file driver (on networks running TCP/IP and NFS) or using the 
iRMX-NET Remote File Driver. 

See also: Accessing remote files. Network User's Guide and Reference; 

TCP/IP and NFS, Network User’s Guide and Reference; 

Accessing NFS files. System Concepts 


DOS Files 

A DOS file is a file located on a DOS-formatted mass storage device; the device 
may be on a network. You access DOS files using the DOS file driver in iRMX III 
or iRMX for PCs systems or by using the EDOS file driver in iRMX for Windows 
systems. 

See also: EDOS file driver. Programming Concepts for DOS and Windows 
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Physical Files 

Each physical file occupies an entire device. Applications can deal with a physical 

file as if it were a string of bytes. Physical files provide these features: 

• An application can have direct control over a device. For example, an 
application can use a physical file to interpret volumes created by other 
systems. 

• Because the application deals with a physical file as a string of bytes, it can 
conserve memory and still communicate with devices that do not need named 
files. These devices include line printers, terminals, plotters, and robots. 

Physical files do not support hierarchical file systems and file access control. 

Stream Files 

Stream files provide another means of intertask communication, as shown in this 

figure. 
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Task A can read from a stream file while Task B writes to it. 

Figure 3-6. Tasks Using a Stream File 

Stream files provide no access control. They are implemented in memory; they 
don't have an attached peripheral device. 

See also: File types. System Concepts', 

Files in BIOS, BIOS and UDI system call summaries. Chapter 1 of 

System Call Reference', 

device connections. System Concepts 
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Devices and Device Controi 


The iRMX I/O Systems provide support for: 

• Device independence through distinct file and device drivers 

• Device control 

• Automatic device reattachment (BIOS only) 

• Terminal Support Code (TSC) to control terminal modes and operation 


Device Independence 

You can use the I/O system calls with a number of devices. This is called device 
independence. Device independence provides flexibility. For example, your 
application may log events as they occur. You can create an application that logs 
events on any device, enabling an operator to route logging from a hard disk to a 
line printer if she needs a printed listing. 

The I/O systems manage devices using/ife drivers and device drivers; the 
separation between the BIOS and the device provides device independence. 

The BIOS, UDI and Shared C Library all use the BIOS. Ultimately, all I/O 
requests your application makes pass through the BIOS to the drivers, then to the 
hardware, as shown in this figure. 
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Figure 3-7. I/O Requests from the Application Go Through BIOS and Device Drivers 


File Drivers 

A/ife driver is a software interface between a device driver and the BIOS. These 
are the file drivers: named, remote, NFS, DOS, BDOS, physical, and stream. 
When you first attach a device, you tell the BIOS which file driver to use for that 
device. Then, the BIOS automatically uses that file driver for the device. 

See also: File drivers and device independence. System Concepts; 

attaching devices. Command Reference 
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Device Drivers 

A device driver is a software interface between a device controller (the hardware 
and firmware) and the file driver. A device driver hides the idiosyncrasies of the 
device from the BIOS. The iRMX OS provides device drivers for many devices. 

Loading and Configuring Drivers 

You can load file and device drivers dynamically at run-time or at initialization. If 
you have an ICU-configurable system, you can select drivers during configuration. 
These drivers become part of the BIOS. 

See also; Supplied device drivers and physical device names in Appendix E, 
Command Reference-, 

Loadable device drivers, in System Configuration and Administration 
and Driver Programming Concepts', 

File and device driver screens, ICU User's Guide and Quick Reference 
You can also write custom file and device drivers. 

See also; Writing your own drivers. Driver Programming Concepts 
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Device Control 


The iRMX OS lets you control; 

• Updating files 

• Disk integrity 

• File fragmentation 

• Buffering with overlapped I/O 

Fixed and Timeout Updating 

Fixed updating and timeout updating are two ways to update devices. They are 
triggered by the passing of set amounts of time. 

You use updating to write all data in a buffer to a designated device, such as a disk, 
at set time intervals rather than just when the buffer is full. Updating can prevent 
loss of data in the event of power failure or other problems. 

Fixed updating occurs when an amount of time, which is specified for an entire 
system, passes. At that time, all devices to which updating applies are updated. 
Fixed updating is independent of I/O activity. 

Timeout updating is defined separately for each device, rather than applying to the 
system as a whole. The timeout period starts at the end of each I/O operation. 

In I/O-intensive systems, you can delay updating by setting the fixed update period 
to longer than the average time between I/O functions. 

Fixed updating is a BIOS configuration value. Stream files and physical files do 
not support updating. 

See also: BIOS screens, ICU User's Guide and Quick Reference', 

lORS, Driver Programming Concepts 


Disk Integrity 

In any computer system, there are many occurrences beyond your control that can 
cause damage to files or disk volumes. For example, power outages can occur just 
as a file is being written, or disk sectors can suddenly become unreliable. The I/O 
systems enable you to maintain disk integrity and determine whether files or 
volumes have been corrupted. The main features are: 

• For hard disks, using system calls to get and set bad track and sector 
information 

• Attach flags and fnode checksum field, which you can check to determine the 
integrity of named volumes and files 

• Disk Mirroring, a hard disk configuration that maintains identical copies 
(mirrors) of data on two hard disks for increased reliability 

See also: Disk integrity. System Concepts 
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Internal File Fragmentation 

When information is stored on a mass storage device, space is allocated in blocks 
called granules. The block size is called granularity. Three kinds of granularity 
are important: 

Device granularity Is hardware dependent, varies among individual mass storage 
devices, and is the minimum amount of data that the device 
can read or write during one I/O operation. For disks, a 
device granule is called a sector; the device granularity is the 
sector size. Each buffer that the I/O systems use when 
reading and writing data is equal to the device granularity. 

Volume granularity Is a multiple of the device granularity and is the minimum 
amount of space that can be allocated to a file at one time. 
You specify the volume granularity when you format the 
volume. The I/O systems use volume granularity when 
deciding where on the volume to allocate this space. 

File granularity Is a multiple of volume granularity. You assign the file 
granularity on a per-file basis when you create a file; the 
granularity applies if the file needs to be extended. 

By selecting the proper granularity values, you can minimize fragmentation of your 
files and balance I/O speed with efficient use of space on the mass storage device. 

See also: Granularity, System Concepts 
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Buffering with Overiapped I/O (ElOS Only) 

The BIOS provides the additional feature of buffering and overlapping of I/O 
operations. The BIOS uses the BIOS, however. Blocking and overlapping are 
more valuable in sequential I/O than in random-access I/O. 

Whenever you open a connection, you specify the number of buffers the BIOS 
uses. This affects how the BIOS reads and writes information through the 
connection: 

Zero buffers This turns off BIOS buffering. The file is accessed each 

time you invoke a system call that reads or writes the file. 
Bor example, if you ask the BIOS to read 30 bytes, the 
BIOS accesses the file and reads exactly 30 bytes. 

The BIOS reads and writes information by blocking 
(transferring one buffer at a time), even though you may 
have specified transferring less. Blocking can improve the 
performance of an application because the BIOS might be 
able to satisfy several additional requests without reading 
the file again. 

Two or more buffers If you request two or more buffers, the BIOS can overlap 
(Overlapping I/O) I/O operations by using read-ahead and write-behind 
algorithms. 

Read-ahead and write-behind enable tasks to continue 
running while the BIOS is transferring information to or 
from devices. This is because the BIOS can accurately 
determine, during sequential reading or writing, the 
location of the next data required by the application. 

You can configure the maximum number of buffers that the 
BIOS can use for files on a particular device. 

Automatic Device Reattachment (ElOS Only) 

The BIOS constantly monitors the status of devices. When an operator removes 
storage media from a drive that is capable of detecting a volume being removed, 
the BIOS detaches the device and deletes all connections to files on the device. 
When the operator replaces the media, the BIOS automatically reattaches the 
device as soon as it is accessed, making it available to the tasks in your system. 

The same principle applies to remote device connections. 

Some devices, such as some 3.5 and 5.25-inch diskette drives, cannot detect a 
volume being removed from the drive. Bor these devices, the BIOS cannot perform 
automatic reattachment. 


One buffer 
(Blocking) 
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Terminal Support Code 

The Terminal Support Code (TSC) is a programmable interface between a terminal 
driver, the BIOS, and a user application. This support code provides a variety of 
special terminal modes and operations. The major capabilities of the TSC include; 

Editing and There are a variety of characters that control and edit 

controlling terminal terminal input. You can replace default control characters 
input with different characters. You can also switch a terminal to 

transparent mode, so that editing and control characters 
have no effect on the input line. 

Type-ahead buffer If you type faster than the OS can read, interpret, and 

respond, the TSC stores the data you type in a type-ahead 
buffer. The OS uses the data from this buffer when it is 
ready for it. 

Controlling terminal You can set the TSC so that output sent to the terminal 
output displays continuously, scrolls a few lines at a time, stops, or 

is completely discarded. 

Escape sequences The TSC accepts escape sequences (characters preceded by 
(translation) an ESC character) to define the characteristics of a 

terminal. This feature enables you to characterize 
terminals so that the I/O system can use standard control 
codes and sequences of codes for all terminals. This is 
called translation. You can use escape sequences to set 
terminal variables, such as the number of lines displayed 
when in scrolling mode. You can change terminal behavior 
by entering in escape sequences or by running a program 
that sends the escape sequences. 

See also: Terminal support code. System Configuration and Administration and 

Driver Programming Concepts 
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System Clock 

Most boards supported by the iRMX OS have an on-board, battery backed-up time- 
of-day clock. The I/O systems use this clock in performing reads and writes. The 
global time-of-day clock is the timekeeper for the entire system. It is accessed only 
during system initialization, by a running application, or when requested by the 
operator. 

The iRMX OS also maintains a local time-of-day clock in memory. The local 
clock is a copy of the global clock but has faster access time, for date and time 
needs. 

The clocks keep track of two items: 

• The current date (day, month, and year) 

• The current time (hours, minutes, and seconds) 

Nucleus, Kernel, and UDI system calls enable your applications to get and set the 
date and time for the local and global clocks. 

See also: Time calls in Nucleus, Kernel, and UDI system call summaries. 

Chapter 1 of System Call Reference 

iS> Note 

The BIOS layer previously provided the system calls to get and 
set the clock time. These system calls are now part of the 
Nucleus. 
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Choosing Between I/O Systems 

This section describes the performance differences between the BIOS and the 
BIOS. It will help you decide whether to use system calls from the BIOS, the 
BIOS, or from both systems. 

Bach of the I/O systems satisfies different requirements. The BIOS offers more 
flexibility and control, while the BIOS offers ease of use. If both systems would be 
useful in one application, you can use both. 

In the iRMX III OS, you can use the ICU to include the BIOS, the BIOS, or both 
systems. In iRMX for PCs and iRMX for Windows, both are included. 


BIOS 


The BIOS provides very powerful capabilities and makes few assumptions about 
the your requirements. The BIOS provides I/O features that are useful in a wide 
range of applications. These features illustrate the flexibility of the BIOS; 

Custom buffering You can design and implement your own buffering 
algorithm technique and control the synchronization between I/O and 

processing. 

Asynchronous You can explicitly control system call synchronization, 

system calls 

Control of details The BIOS system calls have many parameters, which 
enable your tasks to enhance the performance of your 
application system. This is useful in time-critical or 
memory-critical applications and for random-access I/O. 

ElOS 

The BIOS is easier to use than the BIOS, and has these features: 

Automatic buffering You need not become involved with buffering, aside from 
of I/O operations specifying how many buffers the BIOS uses. If your 

application system does not require buffering, you can tell 
the BIOS to use no buffers. 

Synchronous system You do not need to explicitly synchronize system calls, 
calls You can still use overlapped I/O operations using buffers. 

Bewer parameters BIOS system calls require fewer parameters than BIOS 

calls. This simplifies and reduces development time. 
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Making the Decision 

Determine whether your application system requires the flexibility and fine tuning 
capability of the BIOS, the ease of use of the BIOS, or a combination. Before you 
make the final decision, consider these factors. 


Control You may not need the control provided by the BIOS; the time 

required to develop the application system may be more critical than 
fine tuning its performance. 

Memory The BIOS software requires the BIOS, so using both the BIOS and 
the BIOS requires no more memory than using the BIOS alone. 

Implementing some BIOS features yourself (such as buffering) may 
use as much memory as including the whole BIOS. 


Performance Because the BIOS gives your application system control of many 

details, you can probably design your application system to run faster 
with the BIOS than with the BIOS. If you decide to use the BIOS 
anyway, you can improve performance by optimizing the buffer sizes 
and the number of buffers. 


I/O type 


Prototypes 


C Bibrary 
functions 


Choose the BIOS for applications that require very little I/O or use 
random-access I/O. Choose the BIOS when development costs are 
critical, especially in applications that use sequential I/O. 

Use the BIOS to create a prototype application system, and then later 
replace it with your custom I/O system. 

Require both the BIOS and the BIOS. 


Use both layers when your application system uses I/O for several purposes, some 
of which are best accomplished by the BIOS, and others by the BIOS. 
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Examples 

These examples illustrate the advantages of each of the I/O systems. The examples 
assume that you will produce many copies of the application system. 

Application Systems Using Little I/O. If your application system requires very 
little I/O, such as only occasionally logging information to a diskette, use the 
BIOS. The ease of use provided by the BIOS can save you very little time during 
development because the I/O-related part of your system requires so little time to 
develop. Using the BIOS will also save memory. 

Application Systems Using Only Sequential I/O. If your application system 
requires a substantial amount of sequential I/O, a large amount of your 
development resources will be expended in support of I/O. Use the BIOS to save 
time, and because the BIOS provides overlapping I/O. It incorporates read-ahead 
and write-behind algorithms that operate sequentially, and overlaps I/O operations 
and processing. 

High Performance Applications Using Random I/O. If your system performs a 
large amount of random-access I/O, the BIOS is the appropriate choice. 
Performance tuning is also provided by the BIOS. Although such a system might 
require more development time to implement, it should run faster than the BIOS. 


□ □ □ 
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Human Interface Features 


The HI provides several features for both you and the users of your application; 

• Enables loading file and device drivers, system jobs and your application at 
initialization time or run-time 

• Provides HI commands that perform simple programming functions 

• Provides system calls that help you write commands for your application 

• Provides multiuser environment support 

— For the development environment 
— For the application 

• Provides the Command Fine Interpreter (CFI) with its own set of commands 
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Run-time Loading of Jobs 

The HI enables you to load system jobs, networking jobs, file and device drivers, 
and your application when the system boots or dynamically when the system is 
running. Loaded jobs become a part of the iRMX OS until the system is shut down 
or the job is unloaded. Loaded jobs have access to all features of the iRMX OS. 

For iRMX for PCs and iRMX for Windows, this is the only way to load your 
application and the supplied loadable OS jobs. For iRMX III users, the HI enables 
you to change the configuration without using the ICU, then rebuilding (linking) 
the existing system. 

A loadinfo file is executed during HI initialization. You edit this file to load the 
jobs and drivers needed for your application. Jobs and drivers loaded this way are 
child jobs of the HI, as shown in this illustration. 

See also: Descriptions of loadable jobs. System Configuration and 

Administration 
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1 . The HI initialization Task I executes the loadinfo file to load a job into memory from secondary 
storage. 

2. The loaded job is a child job of the HI. 

Figure 4-1. Loading a Job at HI Initialization 
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HI Commands 

The HI commands are small system programs that manage users, files, and devices 
and provide general utilities during development. You can enter commands 
interactively from your keyboard or write them into a file. Some example 
commands supplied with the OS are: 

copy Copies or creates files 

copydir Duplicates a directory and its files and subdirectories 

deletedir Removes a directory, including all its subdirectories and files 

format Formats a disk 

password Adds or deletes users, or changes a logon password 

permit Changes a file's User IDs and access 

rdisk Partitions a hard disk 

shutdown Provides an orderly shutdown procedure for the OS 

sysload Loads a job or driver into memory from secondary storage 

You can include HI commands as part of an application system if you need them. 

See also: Quick Reference to Commands for summaries of commands and 

equivalent commands in the DOS and iRMX OSs; 

Command Reference for complete command descriptions 
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Human Interface System Calls 

The HI provides system calls that enable you to create commands that are 
appropriate to your application and meaningful to your operator. 

By designing commands appropriate to your operators, you can create a user- 
friendly system and reduce operator errors. 

You have great flexibility in creating new commands. The main requirement is 
that the first word in a command must be the name of an executable file on a 
secondary storage device such as a disk. When an operator enters a command, the 
OS loads the named file from secondary storage and runs it. This gives you these 
advantages: 

• You add or modify commands simply by writing new ones. 

• The number of custom commands for a system is not limited by the amount of 
dynamic memory. 

• You do not have to rebuild the system to change commands. 

• Commands used infrequently do not take up RAM space when they are not 
being run. 

See also: Customizing commands. System Concepts 

The categories of system calls for creating commands are: 

• Command-parsing system calls 

• I/O and message-processing system calls 

• Command-processing system calls for invoking interactive HI commands 
programmatic ally 

• Program control system calls to override the default <Ctrl-C> handling task 
provided by the HI 

You can also add commands you need to the development environment if you 
wish. 

See also: Human Interface system call summary. Chapter 1 of System Call 

Reference 
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Custom Command Line Parsing 

The HI system calls for parsing a command line retrieve and interpret parameters 
of a command. 

For example, in an application that monitors toxins in the blood of hospital 
patients, an operator might run a task that displays the toxin level of an individual 
patient or of all patients being monitored. 

You might design a user-friendly approach, with commands oriented to the 
application and operator, rather than computer-oriented commands. For example, a 
command might be; 

toxin of John Doe 

The program toxin issues a system call to receive the parameters John Doe. 
Because filenames are frequently parameters for commands, there are specialized 
system calls to interpret filename parameters. 
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Multiuser Support 

You may need multiuser support in your development environment or for your 
application and operators. In either case, you can use the HI. 

The HI enables: 

• Adding users to the User Definition File (UDF), which defines user attributes 
such as user job memory pool size and user job priority 

• Identifying each user's initial program or CLI (command line interpreter) (the 
program that runs when the user logs on) 

With multiuser support in your development environment, programmers can 
execute commands, run development programs (such as editors and compilers), and 
run applications in a common environment. With multiuser support in 
applications, multiple operators can communicate with your application 
simultaneously. 

You can implement multiuser support another way using simultaneous multiple- 
terminal support with I/O system calls. You might do this if you need to 
implement functions not available with the HI multiuser feature, or if (in an ICU- 
configurable system) you want to exclude the HI layer from the application. 
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HI Initialization 

When the HI begins running, it does these things: 

1 . Executes a system-wide setup. 

2. Initiates user logon. 

3. Creates a user job for each operator or programmer logged on. This job 
provides the environment where programmers develop applications or 
operators use applications. 

4. Starts an initial program or CLI that is the programmer's interface to the OS or 
the operator's interface to the application. 

See also: Logging on, Installation and Startup', 

HI initialization. System Configuration and Administration', 

Multiuser support. System Concepts 

System-wide Setup 

When a multiuser system boots, the HI initializes each terminal in the system as 
either a static logon terminal (a specific operator is always associated with that 
physical terminal) or a dynamic logon terminal (any valid operator can log on and 
use the terminal). You specify the number and types of terminals. 

Multiuser support includes device drivers that communicate with multiple-terminal 
hardware. 

See also: Terminals, System Configuration and Administration 

Logon 

The HI validates terminal users at logon. Terminal operators can: 

• Share a terminal with no logon; all operators share a single user ID 

• Have exclusive use of one terminal 

• Share a terminal; each operator has a user ID and uses a password to log on to 
the OS 

If the terminal is on an iRMX-NET communications network, the operator or 
programmer can use the network to access remote files. 

See also: Accessing remote files. Network User's Guide and Reference 
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Operator Job Creation 

At logon, the HI associates each operator or programmer with a User ID and 
creates for each operator a separate job. These jobs are child jobs of the HI, as 
shown in this figure. 



1 . After the HI initiates user logon, the operator enters a user name and password. 

2. The HI validates the user by checking the User Definition File (UDF). 

3. If the user is valid, the HI creates a user job that is a child job of the HI. The user's initial 
program or CLI runs in the user job. 

4. The user can access and run the application system. 

Figure 4-2. Validating Users With the HI 

When an operator or a programmer creates files or attaches devices, she is the 
owner of those files or devices. Access to the files by other operators or 
programmers depends on the user object created by the owner. 
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Command Line Interpreter (CLI) 

The HI supplies a standard initial program called the Command Line Interpreter 
(CLI). The CLI is the part of the OS you interact with from the command line after 
you install the iRMX OS. The CLI has its own set of commands. 

See also: Getting acquainted with the operating system in Installation and 

Startup, for a brief tutorial on logging on and using commands 

You can use the CLI in the development environment and you can include it for 
your operators in the application if you wish. 

With the CLI, the operator or programmer invokes a command from a terminal 
command line by entering the command name and specifying parameters if 
required. The CLI reads the information from the terminal and executes the 
command as shown in this figure. 
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1 . An operator enters a command at the terminal. The CLI accepts the terminal input and 
parses the command. If the command is a CLI command or a command you have written, 
the CLI executes it after parsing it. 

2. If the command is an HI command, the CLI passes the command to the HI. The HI loads the 
command into memory and executes it. 

Figure 4-3. User Interacts with the CLI 

The CLI provides a number of features: 

Support for different The attributes of any operator's terminal are stored in the 

kinds of terminals termcap file. You can edit this file to change the 

characteristics or to add support for new terminals and you 
can dynamically switch terminal types. 

See also: termcap file, System Configuration and 

Administration 
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Editing and You can input commands at any time, and then press the 

controlling terminal <CR> or <Enter> key (as defined in the termcap file) to 

input send the input to the CEL 

The CLI also contains special function keys, which move 
the cursor, replace the current command line with a 
previous command line, execute a command line, delete 
characters, abort the current command, or continue a 
command onto the next line. 

Type-ahead You can continuously enter command lines. The CLI sends 

the first line to the OS for processing and saves additional 
data in a type-ahead buffer. After the OS finishes with a 
line, the CLI fetches and processes the next line. 

Recalling commands You can retrieve the last 40 command lines entered, then 
edit a line and execute the edited command. 

Background mode You can run commands in background mode, display a list 
of background jobs, and cancel background jobs. 

I/O redirection With I/O redirection, tasks that normally use keyboard 

input and screen output can receive data from and send data 
to files or other I/O devices. This permits tasks to run 
without operator intervention, which is especially useful 
when running in background mode. 

Aliases You can assign and cancel abbreviations for commands. 

You can use the ICU to include your own extensions in the CLI. This enables you 
to add your own features and still retain the capabilities of the CLI. 

See also; Human Interface screens, ICU User's Guide and Quick Reference 

Alternatively, you can supply or create your own initial program that you load at 
HI initialization or load dynamically at run-time. There can be a separate initial 
program for each operator. 

See also: User Attributes Lile, System Configuration and Administration 
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Application Loader Features 


The AL enables tasks to load programs from secondary storage into memory at run- 
time. The loaded program can run in the calling task's job or it can run as an I/O 
job, as shown in this figure. 
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1. Task A is part of an I/O job. 

2. Task A calls the AL to load a program into memory from secondary storage. 

3. The AL creates an I/O job for the program to be loaded. 

4. The AL creates the initial Task I and loads the program into memory. 

Figure 5-1. Using the Application Loader To Load a Program Dynamically 

Because the loaded job is the child of a job you have created, you can receive 
notification when the loaded job is deleted if you wish. 
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Dynamic Loading 

The AL performs dynamic loading; it modifies appropriate addresses in the 
program at the time it loads the program. Dynamic loading offers flexibility in 
designing and maintaining application systems: 

• The AL loads the programs anywhere in available memory. If you add more 
memory to the system, the AL will use it. 

• You can change programs without rebuilding (linking) the existing system. 

• If you have memory restrictions, you can store seldom-used programs on 
secondary storage until you need to run them. 

• You can use overlay modules to execute programs that are actually larger than 
the memory available. 

The AL can load object code from any device if the device supports iRMX named 
files and you have the appropriate device driver. The AL requires programs to be 
object code and meet certain other requirements. 

See also: RCONFIGURE control, STL format, SEGSIZE control, 

DYNAMICMEM, System Concepts', 

object code, object file, and object module. Glossary in this manual 

Loading Flat Model Applications 

The Application Loader can recognize and load an application that you write using 
a flat-model (non-Intel) compiler. Flat model applications require that you use the 
paging subsystem provided with the OS. 

See also: C Compilers, Flat Model, Programming Techniques', 

flat.job, paging.job. System Configuration and Administration 
Paging System Calls, System Call Reference 
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Objects and System Calls 

Most AL system calls require the BIOS because they use connection objects and 
I/O jobs. 

The AL provides synchronous and asynchronous system calls. To overlap 
processing with loading operations, use asynchronous system calls. If the calling 
task can wait until the new program is loaded, use synchronous system calls, which 
are easier. 

You can also use the AL to load a program into the calling task's job, as shown in 
this illustration, but this requires additional programming effort. 
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1 . Task A calls the AL to load a program Into memory from secondary storage. 

2. The AL loads the program into a memory segment in Task A's job. 

Figure 5-2. Using the Application Loader To Load a Program into a Task's Memory 


See also: Application Loader system call summary. Chapter 1 of System Call 

Reference', 

Application Loader, System Concepts 
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Overlay Loading 

Where memory is extremely limited, you can use overlay loading to conserve 
memory but the price is slower execution. You can designate two modules that are 
never required in memory at the same time in the logical flow of the program as 
overlays. Each overlay occupies the same area of memory but runs at a different 
time. 

See also: Overlays, System Concepts 

You can use the ICU to include or remove the AL, or you can select the features of 
the AL to meet your exact needs. 

See also: Application Loader screens, ICU User's Guide and Quick Reference 


□ □ □ 
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UDI Features 


The UDI is a high-level interface to the iRMX OS: a set of system calls enabling 
language software (such as compilers, interpreters, assemblers, or run-time 
systems) to use the OS. 

If an application makes only UDI system calls with no explicit calls to an iRMX 
OS, you can transport the application between other OSs that also support the UDI. 
If you want portability, don't mix UDI calls with BIOS and BIOS calls. This figure 
illustrates the relationship between the application code, the layers of software and 
the processing hardware. 


Application code in application language(s) 


Run-time libraries for 
non-mathematical features 




UDI libraries 




Operating system interface libraries 

^ 


Operating system 


Intel387™ 

support 

library 


Microprocessor 


Floating-point 

Instructions 


W2570 

The downward arrows represent system call flow and data flow from the application down to the 
hardware, where the calls are ultimately executed. In this case, the application does not make 
direct calls to the OS, but interacts through the UDI software. The figure does not show the 
upward flow of data from the hardware to the application code. 

Figure 6-1. UDI Interface Between the Application and the Hardware 
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When you use the UDI, you can switch OSs by changing the UDI library. The UDI 
libraries always present the same interface to the application, but the interface with 
the OS is designed specifically and exclusively for that OS. There are UDI 
libraries for the iRMX, iNDX, UNIX, and XENIX OSs. 

The UDI system calls behave somewhat differently when used in different OSs. 
This is because each OS has many unique characteristics, and some of them are 
reflected in the results of the UDI calls. 

You can run any language on the iRMX OS as long as the language processor uses 
the UDI standard system calls and the Object Module Format (OMF) is compatible. 
The UDI software interface provides two major advantages: 

• A language processor can use well-defined, appropriate, standard calls to 
communicate with the iRMX OS. You can easily adapt existing languages to 
run on the OS. 

• Any language processor or software tool using UDI system calls, including 
user- written programs, is portable. 

See also: UDI system call summary. Chapter 1 of System Call Reference', 

UDI, System Concepts 

For the UDI, the only ICU-configurable option is whether to include the UDI in 
your system. 

See also: SUB screen, ICU User's Guide and Quick Reference 


□ □ □ 
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Networking Features 


A network is a group of independent computers connected together to exchange 
information. This chapter describes the software and hardware that Intel provides 
for this purpose, and provides some basic networking concepts and structure. 

See also: Network User's Guide and Reference, Programming Concepts for 

DOS and Windows, and TCP/IP and NFS for the iRMX Operating 
System 

Network Concepts and Terminology 

An individual computer system is a node in the network. The node you are logged 
into is the local node, any other one is a remote node. The nodes are connected 
into a Local Area Network {LAN), usually by a physical connection such as 
Ethernet. Systems on a network can share resources such as files, printers, diskette 
drives, tape drives, and modems. Nodes on an iRMX network can exchange 
information with computers using other OSs, such as UNIX or DOS. This is called 
interoperability . 

iNA 960 provides programmatic access to transport services and iRMX-NET 
provides transparent file access. An ICU-configurable system running iRMX-NET 
can be configured as a server (a computer that provides resources), a client (a 
computer that requests resources), or both. Typically, iRMX systems run both the 
iRMX-NET client and server jobs. 

TCP/IP for iRMX OSs includes Telnet, ETP, and TETP for remote login and file 
access. NES provides transparent file access. Any iRMX system can be both a 
client and a server for TCP/IP services and for NES. 

Each network can be divided into smaller units. These are called Administrative 
Units (AUs) in iRMX-NET. An AU is a group of systems that has the same set of 
users. 

You can set up multiple subnets in both iNA 960 and TCP/IP. A subnet is used for 
dividing a network into reasonable sizes or logical groups; systems in the subnet do 
not necessarily have the same users. To communicate between subnets you 
implement routing on a node connected to two or more subnets. 
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A special feature of iNA 960 allows boards in a Multibus II system to treat the 
backplane as a virtual Ethernet connection without any Ethernet hardware. This 
Multibus II subnet lets more than one board in the system run TCP/IP software. 
With a router in the system, boards that do not have a network interface card (NIC) 
can access the LAN over the Multibus II subnet. 

Network Software 

You can use 1NA960 by itself to provide programmatic access to the network. 
Along with iNA 960 you can run iRMX-NET to provide transparent file access. 
You can run TCP/IP along with iNA 960. To use NES for transparent file access, 
you must run TCP/IP. 


TCP/IP for iRMX OSs 

TCP/IP network software enables users to access other computers on the network. 

You can configure TCP/IP as both a first-level job by using the ICU, or as a job 

loaded through the sysload command. TCP/IP supports these features: 

• Telnet client and server software provides virtual terminal access to and from 
non-iRMX computers. 

• Pile Transfer Protocol (PTP) client and server software enables file transfers to 
and from other computers, as well as basic directory management. 

• Trivial Pile Transfer Protocol (TPTP) client and server software enables 
transfers of public files to and from other computers. 

• Berkeley R-series commands rep, rsh, and rlogin allow you to perform 
operations from your local host on any remote host that also supports these 
commands. 

• Network Pile System (NFS) client and server software enables transparent 
access of remote files and directories using TCP/IP protocols. 

TCP/IP software provides industry standard networking protocols. This enables 

interoperability with most other OSs. Administrators of multiple OS networks, as 

well as many users, are likely to be familiar with TCP/IP networks. 

See also: TCP/IP and NFS for the iRMX Operating System for more details 
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iNA 960 and iRMX-NET 


iNA 960 provides general-purpose network communication services, including the 
Data Link, Network, and Transport layers defined in the Open Systems 
Interconnection (OSI) model. By itself, iNA 960 provides a programmatic 
interface to the International Standards Organization (ISO) OSI protocol. 

iRMX-NET is part of Intel's family of OpenNET Local Area Network (LAN) 
products. The iRMX-NET software requires the Nucleus and BIOS layers and an 
underlying iNA 960 job. iRMX-NET is compatible with Microsoft MS-NET for 
DOS platforms. iRMX-NET provides transparent file access and user-interface 
commands. 

iNA 960 includes: 


iRMX-NET includes: 

Server job 

Client job, including 
Eile Consumer and 
Remote Eile Driver 
(RED) 

iNA 960 and iRMX-NET operate within the Open Systems Interconnection (OSI) 
Reference Model, a seven-layer reference model defining network architecture. 

The iNA 960 software operates in either of two hardware environments: 
COMMengine (offboard NIC) or COMMputer (onboard NIC). 

iNA 960 supports Multibus I, Multibus II, and PC bus architectures and is provided 
as a set of ICU-configurable and loadable jobs, each specific to the particular bus 
and LAN hardware. 

See also: iNA 960, iRMX-NET, COMMengine and COMMputer, Network 

User's Guide and Reference', 

Network jobs. System Configuration and Administration 


ISO transport software that provides general-purpose 
services, including the Data Link, Network, and Transport 
Layers as defined in the ISO OSI model. iNA 960 is 
available as customized jobs suitable for particular NICs. 

You can use iNA 960 with or without iRMX-NET. When 
used by itself, iNA 960 provides only a programmatic 
interface to network services through layer 4 in the OSI 
Reference Model. 


Allows remote systems to access public files on the local 
system. 

Lets you access public files on any system that runs the 
server job, as if the files were local 
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Network Security 

Any iRMX-NET network must have at least one AU; an AU can be as small as a 
single system. AUs provide easy maintenance and security. 

iRMX-NET uses two files for network definition and security; 


User Definition 
Eile (UDE) 


Client Definition 
Eile (CDE) 


Defines users. The same user can be in multiple AUs, but 
must have a unique ID in each one. A client uses the UDE 
to validate a user when the user logs on. 

Defines clients with names and passwords. A server uses 
the CDE to validate a client when the client establishes a 
connection with it. 


The system administrator sets up and maintains the AUs, UDE, and CDE. 

See also: Network Administration, AUs, UDE, CDE, in Network User's Guide 

and Reference', 

UDE, CDE, in System Configuration and Administration 

Eor TCP/IP users, the Telnet, ETP, and TETP applications each provide some level 
of security when accessing file-based data. NES users are provided with Unix and 
Short style user authentication, but not with DES encryption as described by 
Request Eor Comment (REC) 1057. 
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Networking Between Operating Systems 

Using the appropriate networking software, you can exchange information with 
computers using other OSs, such as UNIX and DOS. If you use iRMX-NET, these 
different systems interoperate using the Network File Access (NFA) protocols. 

Fach OS must run with a corresponding OpeuNFT product that uses NFA 
protocols. 

This figure illustrates the interoperations of an iRMX OS using the iRMX-NFT 
Software with other OpenNFT systems, and the relationship between a server and a 
client. The direction of the arrows indicates the flow of resource requests. 


Servers Clients 



Figure 7-1. iRMX-NET Interoperability with other OpenNet Systems 


The left side of the figure shows an iRMX system configured as a client with 
iRMX and UNIX systems operating as servers. The right side of the figure shows 
an iRMX system that is configured as a server for iRMX, UNIX, and DOS clients. 

TCP/IP for the iRMX OSs provides interoperability with OSs running TCP/IP and 
Telnet, FTP, TFTP, or NFS servers. 

See also: Interoperability, Network User's Guide and Reference 
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iRMX for Windows Networking 

iRMX for Windows gives DOS and the iRMX OS simultaneous access to network 
services. In iRMX for Windows, networking provides these additional benefits: 

• DOSAVindows and iRMX running on the same CPU can share a single 
network controller. 

• DOSAVindows networking applications can use the Multibus I and Multibus II 
network controllers with the iRMX OS. 

• A remote file client can access DOS files without a dedicated DOS file server. 

• Network applications previously running on separate DOSAVindows and 
iRMX systems can run unchanged on a single iRMX for Windows system. 

• Applications developed on one iRMX for Windows hardware configuration 
can run on another iRMX for Windows hardware configuration without 
change. 

NetRDR 

The iRMX for Windows OS includes an additional piece of networking software, 
the Network Redirector (NetRDR). It has two parts: a NetBIOS driver installed as 
a resident program on DOS, and an iRMX job. NetRDR directs DOS requests for 
networking to the iRMX OS. DOS and iRMX network applications can share the 
network controller and have concurrently access to the DOS file system. 

With NetRDR, DOS network software and iRMX-NET can share the network 
controller, enabling applications on both OSs to communicate across the network. 

With iNA 960 and/or iRMX-NET (not TCP/IP), iRMX for Windows is also 
compatible with Novell's NetWare, and it is possible for iRMX-NET,, MS-NET, 
and Novell to coexist on a network. An iRMX for Windows system can function as 
a NetWare client, using either Intel's PCL2(A) board or another Novell-supported 
Network Interface Adapter such as 3Com's 3C503 board. The iRMX OS can 
access files on DOS-controlled networks such as Novell and can act as a gateway to 
such networks. 

You can use two programmatic interfaces for developing DOS networking 
applications: 

• The NetBIOS interface provided by the NetBIOS driver 

• The iNA 960 request block (RB) interface 

Only the iNA 960 RB interface is available to iRMX applications. 

See also: Using iRMX-NET in a DOS Environment, System Configuration and 

Administration 
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X.25 Networking 

In the Multibus II environment you can access an X.25 network from any Multibus 
II board. Two Multibus II board modules support X.25 communications: the 
MIX232 and MIX422 Communications Controller modules. On a MIX baseboard 
with one or more of these modules, you run an X.25 server job. On any other CPU 
board(s) in the system you can run an X.25 client job along with your X.25 
application. 

Your application makes calls to the X.25 client, which uses Multibus II messages to 
communicate with the X.25 server on the MIX board. The X.25 server accesses the 
X.25 network. 

The X.25 network is based on the International Telephone and Telegraph 
Consultative Committee (CCITT) data transfer protocol. Your application can 
make calls to any layer of the protocol, including the Physical, Frame, and Packet 
layers. 

See also: X.25 User’s Guide and Reference for programmatic access to the X.25 

network and software 

Other OS Features that Use Networking 

An application on any iRMX OS can use DDE (Dynamic Data Exchange) to 
communicate with Windows-based systems, using either a TCP/IP or OpenNET 
network. 

See also: DDE, Programming Concepts for DOS and Windows 

The Soft-Scope for Windows debugger can operate from a remote Windows-based 
system connected to a target by a TCP/IP network. 

See also: Soft-Scope Debugger User’s Guide 


□ □ □ 
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System Development 


The iRMX OS helps you develop real-time application systems quickly and enables 
you to concentrate on the software that relates specifically to the application. The 
OS includes: 

• Intel's industry-standard languages: 

— PL/M 

— C 

— Assembler 

You can also use non-Intel tools, such as Microsoft, Borland and Watcom C. 
See also: C compilers. Programming Techniques 

• Shared C library 

• These software tools for editing and building ICU-configured systems: 

— Aedit text editor 

— BLD386 

— BND386 for linking your code 
— OH386 
— Mapper 
— Librarian 

• These debuggers: 

— Soft-Scope for Windows and Soft-Scope III for the iRMX command line 
— iRMX static System Debugger (SDB) 

— System Debug Monitor (SDM) 

See also: Application debugging, in this manual; 

Programming Techniques and Aedit Text Editor, 

System Debugger Reference 
Soft-Scope Debugger User’s Guide 

• Online help 

You can develop your code on the same computer that will run your application 
(on-target development) or develop on one for installation later on a another 
platform. 

See also: Installation options. Installation and Startup-, 

Development environment, ICU User's Guide and Quick Reference 
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Shared C Library 

The C library supports hundreds of C functions and macros for applications that run 
in the multi-tasking iRMX OS environment. This includes many standard C 
functions that enable applications to perform common I/O operations without 
making direct iRMX system calls (OS-independent). There is also support for 
iRMX OS-dependent operations such as multitasking, time-of-day, signal 
management, and environment management; this enables you to create portable 
code using standard ANSI and POSIX programming practices. You can mix C 
library calls with direct iRMX system calls. 

The Shared C library, sharable by multiple tasks and jobs, is available as an iRMX 
OS extension job in two ways: 

• Run-time loadable job. 

• Resident first level job in ICU-configurable systems. The C Libraries require 
both the BIOS and BIOS. 

Any number of tasks and jobs (up to the maximum that the OS allows) may share 
the C library concurrently, each with its own independent C environment. The C 
library automatically manages common system resources such as I/O interfaces and 
memory when your code makes C library calls that use these resources. 

See also: C Library Reference for information on supported functions 

Online Help Systems 

These online help systems are included: 

• Windows Help for iRMX system calls and condition codes (Windows systems 
only) 

• Manuals viewable in Adobe Acrobat (.PDF) format (Windows systems with 
CD-ROM drive only) 

• Help for iRMX commands (at any iRMX command line prompt) 

• The Interactive Configuration Utility (at the ICU prompt) 

See also: Using online help. Installation and Startup-, 

help command. Command Reference', 

ICU help screens, ICU User's Guide and Quick Reference 
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System Design 

There are some general guidelines for designing and developing real-time systems. 

The first step is to define the application. This step should include; 

• Listing all the various inputs and outputs in the application. Decide which 
objects to use for intertask coordination and communication. 

• Listing all the tasks that need to be done to produce the input and output. 
Define interrupts and decide which ones require determinism. Assign interrupt 
levels and priorities to take advantage of multitasking and preemptive, priority- 
based scheduling. 

• Develop the detail for each task in a block diagram. 

• Decide if the application requires multiple jobs, and if so, how they will use 
shared memory and dynamic memory allocation. 

• Design your user interface. 

• Determine if you require custom devices. Decide whether to use loadable or 
resident file and device drivers. Decide whether to use custom or Intel- 
supplied drivers. 
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This flowchart shows steps typically taken by iRMX designers. 



OM02725 


1. Define jobs. Define tasks, interrupt levels, and priorities. Decide which objects to use. 
Define interrupts, handlers, and levels. 

2. Decide whether to use loadable or resident file and device drivers. Decide how to implement 
a multiuser environment and/or an operator interface. 

3. Decide if you need custom hardware that solves some unique problem or gathers data in a 
unique way. 

Figure 8-1. Typical Development Cycle for iRMX Applications 


At the completion of these steps, the prototype system is ready to be tested, 
debugged, and fine-tuned. 
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A Hypothetical System 

This hypothetical application system monitors and controls dialysis. The system 
consists of three main hardware components, as shown in this figure. 



1 . A bedside unit is located by each bed. Each unit contains a processor board with the iRMX 
OS, which performs these functions: 

- Measures the toxins in the blood as it enters the unit 

- Adjusts the rate of dialysis 

- Removes toxins from the blood 

- Generates the bedside display for bedside personnel 

- Accepts commands from the bedside personnel 

- Sends information to the MCU 

2. The master control unit (MCU) is a PC with a screen and a keyboard. This system also runs 
a version of the iRMX OS. The MCU enables one person to monitor and control the entire 
system. It performs these functions: 

- Accepts commands from the MCU keyboard 

- Accepts messages from the bedside units (toxicity levels, bedside commands, 
emergency signals) 

- Creates the display for the MCU screen 

3. iRMX-NET connects the bedside units to the MCU. 

Figure 8-2. The Hardware of the Dialysis Application System 

The next sections describe how various iRMX features are used in the hypothetical 
system. 
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Interrupt and Event Processing 

Interrupts and internal events occur at the bedside units: bedside personnel enter 
commands asynchronously and the system computes toxicity levels at regular 
intervals. 

Toxicity levels, measured as the blood enters the bedside unit, are not subject to 
abrupt change. The machine slowly removes toxins while the patient's body, more 
slowly, puts toxins back in. The result is a steadily declining toxicity level. The 
bedside units must monitor toxicity levels regularly, but not too frequently. For 
instance, the bedside units could compute the toxicity levels once every 10 
seconds, using a clock for timing. The measurement task would measure and 
compute the toxicity, put the information in a mailbox for the MCU, and suspend 
itself for 10 seconds. 

Command interrupts from the bedside unit occur when a medical operator types a 
command and presses <Enter>. Interrupts from command entries occur at random 
times. The interrupt handler signals the interrupt task. The interrupt task performs 
any required processing and waits for the next interrupt. 

Processing Commands From the Bedside Units 

Each time a medical operator types a command and presses <Enter>, the bedside 
unit receives an interrupt signal from the terminal. The bedside unit stops 
executing the current instruction and begins to execute an interrupt handler. 

1 . The interrupt handler accumulates the characters in a buffer and puts them in a 
segment. The interrupt handler signals the interrupt task for bedside 
commands. 

2. The interrupt task gets the contents of the segment where the handler put the 
command. It parses the command and does the required processing. 

3. It puts the command information, along with the number of the bedside unit, 
into a message. 

4. It sends the message to the predetermined mailbox for the MCU. 

5. The interrupt task begins waiting for the next interrupt. The system returns to 
its normal priority-based, preemptive scheduling. 

Multitasking 

Tasks in the application run using preemptive, priority-based scheduling. This 
allows the more important tasks, such as those controlling the rate of dialysis, to 
preempt lower-priority tasks, such as updating displays. New capabilities could be 
added to the system by simply adding new tasks. 


112 


Chapter 8 


System Development 



Intertask Coordination 


A number of mailboxes used to send information from one task to another are the 
only form of intertask communication. 

Enhancing the System 

Multi- The application can perform statistical analysis in a different job. 

programming The statistical application and dialysis application don't need to 

share any objects. Using two different jobs minimizes the chance 
that one application can affect the other. 

If the two applications need to share a little information, the shared 
data can be passed from one job to the other without losing the 
benefits of isolation. 

The application can include recording information about patients in 
files on tape, diskettes and hard disks. 

If the application is extended to allow the MCU operator to send 
recorded data to several devices (such as a printer, magnetic tape, 
or disk), the device-independent I/O system enables recording the 
data without adding code specific to each possible device. 


Mass storage 
files 

Device 

independence 
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Bootstrap Loading (iRMX III OS and iRMX for PCs) 

The iRMX III OS and iRMX for PCs provide a Bootstrap Loader that enables your 
application system to reside on disk and be loaded into RAM (random access 
memory) when the system starts. 

The Bootstrap Loader resides partly in ROM (read-only memory) and partly on 
disk on your application hardware. When your system is reset, the Bootstrap 
Loader receives control, and loads the rest of the software, including the iRMX OS 
and the application software, into RAM. The Bootstrap Loader provides these 
advantages: 

• By placing the Bootstrap Loader in ROM, you can shift the rest of your 
application system to RAM. This decreases the amount of ROM required. 
Since ROM requires that information be burned or masked into memory, the 
Bootstrap Loader reduces your masking or burning expenses and 
manufacturing costs. 

• The Bootstrap Loader simplifies providing updated software to your 
customers. You can ship diskettes containing the updated software, reducing 
the cost of updating your software. 


□ □ □ 
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Application Debugging 


The iRMX OS provides several levels of debugging support. Sometimes you will 
use the features listed in this section as part of your system, and sometimes you will 
use them only during development. 

System Debug Monitor 

The System Debug Monitor (SDM) is an assembly-level debugger that enables you 
to load and run code, examine registers and memory, and disassemble code. 

This monitor is soft-loaded into RAM. The monitor can run on target on a stand- 
alone development system, or in a development environment with a separate iRMX 
host and target. 

The SDM monitor provides commands that perform these functions: 

• Load and execute the code module 

• Examine and modify memory and CPU registers 

• Display the contents of descriptor tables (protected mode only) 

• Move, compare, and search blocks of memory 

• Read and write to an I/O port 

• Disassemble code and execute one instruction at a time 

• Disassemble code and sequentially execute instructions until encountering a 
call instruction 

See also: SDM, System Debugger Reference 
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System Debugger 

The iRMX System Debugger (SDB) extends the capabilities of SDM. It provides 
static debugging for when the system hangs or crashes, when you wish to freeze the 
system and examine it, or when synchronization requirements preclude debugging 
selected tasks. By stopping the system, the SDB provides a global view of the 
system. The SDB requires only the Nucleus to run. 

The SDB enables you to; 

• Identify and interpret iRMX system calls 

• Examine a task's stack to determine system call history 

• Display information about iRMX objects 

• Display information about the job hierarchy 

• Display the register contents 

• Single step 

See also: System Debugger Reference for details on debugging 

Soft-Scope Debugger 

The Soft-Scope debugger is a tasking debugger, which enables multiple tasks to be 
debugged simultaneously while the rest of the system continues to run. It is an 
interactive, source-level, symbolic debugging tool that enables debugging code 
modules at the source level, such as C or PL/M, rather than at the assembly level. 
There are two versions of this debugger; 

• Soft-Scope III is installed with the OS. It operates from the iRMX command 
line; you invoke it with the command ss. 

• Soft-Scope for Windows is installed from diskettes separate from the OS 
installation; you invoke it as sswin. In an iRMX for Windows system you can 
run Soft-Scope locally on Windows, using the same system as the application 
you are debugging. With any iRMX OS you can run Soft-Scope remotely on a 
Windows-based system that is connected to the target iRMX system with a 
serial cable or a TCP/IP network. 
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You do not have to deal with the details of the CPU's machine code, or with the 
inner workings of the iRMX OS. Features of the Soft-Scope debugger include: 


• All of the features of SDB and SDM 

• Full-screen windowed display, mouse- or keyboard-activated menu and dialog- 
boxes (Windows version) 

• Source code interface and online listings 

• Access to program variables by source-code name, including arrays, structures, 
and bit fields 

• High-level breakpoints, execution breakpoints in ROM, and access to data 
breakpoints 

• Disassembly of instructions 

• Second terminal option for remote debugging 

• Unlimited size of source files and number of symbols 

• Ability to create C-like macros and C-like expression syntax within commands 

• Run-time exception handling 

• Ability to suspend and resume tasks 

• Full support for the protection features of the microprocessor, including 
automatic trapping of protection exceptions 

See also: Soft-Scope Debugger User’s Guide: the first manual bound into this 

volume describes Soft-scope for Windows; the second manual 
describes Soft-Scope III for the iRMX command line 


□ □ □ 
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System Configuration 


Configuration really means two things: 

• Setting up your development system to include the programmers and terminals 
in your work environment 

• Modifying the iRMX OS as your application requires, before installing it on 
your application systems 

See also: Configuring users and terminals in System Configuration and 

Administration for information about configuring the development 
environment 

You can use the Interactive Configuration Utility (ICU) and/or loadable jobs and 
drivers to modify your OS configuration. 


ICU Configuration 

You can configure any iRMX OS with the ICU. In an iRMX for Windows or 
iRMX for PCs installation you must specify a generation environment if you want 
to include the ICU. The iRMX III OS always includes an ICU and the underlying 
generation tools. The ICU creates a custom system for your application. It enables 
you to choose and modify the parts of the OS you need. 

The OS installation contains preconfigured bootable images of the iRMX OS that 
you can use. The ICU definition files used to create these images are also 
included. Using the definition files provides these advantages: 

• You don't have to make hardware or software changes to install the OS on 
Intel's System 310, 320, and 520 microcomputers. 

• The start-up systems use the most current, complete, and accurate version of 
the OS. 

• You can start using the OS immediately, and perhaps even run your application 
software, without redefining or reconfiguring the OS. 
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The advantages of using the ICU include; 

• You can configure application systems, even complex systems, relatively 
easily. The ICU displays a series of menus, each describing a number of 
features. You can accept the default or change the value for each feature. 

• The choices you make during configuration are saved in a definition file. You 
can use this file later as a base when you need to change your configuration. 

See also: ICU User's Guide and Quick Reference for details on using the ICU 

screens and for a list of definition files 


iRMX for PCs and iRMX for Windows Configuration 

At installation, the system asks questions about the system bus type, networking, 
etc. Then it sets up an initial configuration. 

You can further configure iRMX for PCs and iRMX for Windows by modifying an 
initialization file, rmx.ini. With this file, you can modify parts of the OS, although 
you cannot exclude layers. 

During initialization, each layer reads a block of entries from this file. The values 
you enter here override the default values shipped with the software. 

See also: rmx.ini in System Configuration and Administration 

You can also use loadable jobs and drivers to modify your configuration. 


Loadable Jobs 

Loadable jobs enable you to add drivers, networking, the C library, and your 
application to the OS either during initialization or dynamically while the system is 
running. Loading jobs dynamically reduces the size of the boot image and can help 
conserve memory if you remove jobs when you no longer need them. You can also 
load custom device and file drivers you have written. 

Typically you load jobs and drivers with the HI sysload command in the loadinfo 
file when the system initializes. Loaded jobs become a part of the OS and remain a 
part of the system until you explicitly delete them or reboot the system. The 
loadinfo file is one of the files in the tconfig: directory. 

See also: Loadable jobs, sysload command. Command Reference', 

Loadable jobs and drivers. System Configuration and Administration', 
Writing drivers. Driver Programming Concepts 


□ □ □ 
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Related Publications 


iRMX Manual Set 

Startup Manuals 

• Installation and Startup 

• Introducing the iRMX Operating Systems 

Programming Concepts Manuals 

• iRMX System Concepts 

• iRMX Driver Programming Concepts 

• iRMX Network User's Guide and Reference 

• TCP/IP and NFS for the iRMX Operating System 

• Programming Concepts for DOS and Windows 

• iRMX Programming Techniques and Aedit Text Editor 

• iRMX X.25 User’s Guide and Reference 

• How to Use the Peripheral Controller Interface (PCI) Server 

• Real-Time and Systems Programming for PCs, by Christopher Vickery 

Reference Manuals 

• iRMX Command Reference and iRMX Quick Reference to Commands 

• iRMX System Call Reference (also online for Windows users) 

• iRMX C Library Reference 

• iRMX System Debugger Reference 

• iRMX Master Index 
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Configuration Manuais 

• iRMX System Configuration and Administration 

• MSA for the iRMX Operating System 

• ICU User's Guide and Quick Reference 

Toois Manuais 

• ASM386 Macro Assembler Operating Instructions and 
ASM386 Assembly Language Reference Manual 

• iC-386 Compiler User's Guide 

• Intel386 Family Utilities User's Guide 

• PL/M-386 Programmer's Guide 

• Soft-Scope Debugger User’s Guide 
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Glossary 


absolute address 

access control 

access rights 

AL 

alias 

ANSI 

application name, DDE 
application system 
asynchronous 

asynchronous 
system call 

attributes 

AU 


The physical address that is permanently assigned to a storage 
location in memory. 

Controlling a user's access to perform selected operations, such as 
reading or changing, on an object, file, or directory. 

The bit settings that determine a user's permission to perform 
operations on an object, file, or directory. 

Application Loader loads programs into memory and executes them 
from an application program. 

A symbolic name for an object, file, directory, command, etc. 
American National Standards Institute. 

The name of the server application, also known as the service 
name. 

The set of components needed to solve an application problem: 
your program, other software, and hardware. 

Non-synchronous timing. A method in which signals between 
networked systems are not timed; sending data a character at a time 
without prior arrangement. An event or device that is not 
synchronous with CPU timing or another device's timing. See 
synchronous. 

Can run concurrently with the calling task. See synchronous 
system call. 

The set of characteristics and properties that define a given object 
type. 

Administrative Unit. An iRMX-NET concept that defines a logical 
grouping of systems in a network. The systems that share a 
common set of users. 
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background process 

BIND 

binding 

BIOS 

blocking 

boot 

boot client 

bootloadable 

bootstrap 

bootstrap loader 

buffer 
buffer pool 
buffered device 

cache 
call gates 


A command or program that runs without interaction with the 
operator, and allows the operator to enter other commands while it 
is running. 

Linking object modules using the BND386 utility. 

Letting each task know the locations of the variables and 
procedures that it uses. 

The Basic I/O System layer of the iRMX OS. This is different 
from the ROM BIOS stored in ROM on a DOS system. 

Two meanings: reading or writing a file in sector-size blocks; a 
system call waiting at an exchange until a necessary resource or 
object is available. 

To use a bootstrap loader. This term is generally used to describe 
starting a computer system. 

The system that requests a remote boot from the remote boot 
server. Typically, this system does not have mass storage provided 
by a hard disk or diskette drive. A diskless system or workstation. 

A program with absolute addresses instead of relocatable addresses. 

Starting a computer, which usually clears memory, sets up I/O 
devices, and loads the OS. 

A program that resides in ROM. When the system is reset, the 
bootstrap loader receives control, and loads the OS and application 
software into RAM. 

A temporary holding area for memory segments; used for reading 
and writing data. 

A collection of preallocated buffers that provides quick access to 
reusable memory. 

An intelligent communications device that has its own CPU. It 
manages its own character buffers separately from those managed 
by the Terminal Support Code or Random Access Support Code. 
See non-buffered device. 

A high-speed buffer memory used between the CPU and main 
memory. Instructions and programs can operate at higher speed if 
they are in the cache. 

Redirect flow within a task from one code segment to another. 

Used to enter the iRMX OS and OS extensions. 


124 


Glossary 



CDF 

Client Definition File. Contains the names and passwords of client 
systems in a network's Administrative Unit. 

channel 

A data path. 

checksum field 

A field in the fnode file used to verify disk integrity. 

child job 

A job created by another job, called the parent job. Child jobs 
obtain their resources, such as memory, from their parent job. 

:ci: 

Standard logical name for the terminal keyboard, or console input. 
Each user's :ci: refers to the terminal associated with that user. 

CLI 

Command Line Interpreter, the default initial program; includes 
commands with optional parameters. 

client, DDE 

The application that responds to the query by the server. An iRMX 
application can be a client for one conversation and a server for 
another. 

client, network 

A network system that requests and uses resources located at 
another (remote) network system. Intel's transport protocol is based 
on the client-server model, in which client jobs request data from 
server jobs, and server jobs respond to the requests. Sometimes 
called consumer. 

:co: 

Standard logical name for the terminal screen, or console output. 
Each user's :co: refers to the terminal associated with that user. 

command line parsing 

Retrieving and interpreting the parameters of a command. 

COMMengine 

A networking hardware environment that uses separate boards for 
the host CPU and LAN controller. The iNA Transport Software 
runs on the LAN controller and the iRMX-NET runs on the host 
CPU with iRMX OS. 

COMMputer 

A single-board computer with on-board integrated networking 
hardware. The COMMputer hosts iRMX-NET, iNA 960, and the 
iRMX OS. 

composite object 

An object of a new type designated by an extension object. 

concurrent condition 
code 

A condition code that is returned as a result of asynchronous 
processing. 

condition code 

A message returned when an error occurs during execution of a 
program or system. Same as exception or error code. 


Introducing the iRMX Operating Systems 


Glossary 


125 



configuration 


Using the ICU to change attributes about the iRMX III OS. Also 
loading and modifying :config:, rmx.ini, and loadinfo files in iRMX 
for PCs and iRMX for Windows. 


connection 

console 

conversation, DDE 

CPU 

CPU trap 
current directory 

datagram 

data file 
data item, DDE 

deadlock 

dedicated server 

default prefix 

descriptor 

descriptor table 


An object, returned by the I/O system whenever a file is created, 
that represents the bond between a device or file and a program. 

A specific terminal attached to a system that is used to invoke the 
Bootstrap Loader. 

Any two applications that pass DDE data items from one to 
another. 

The central processing unit of a computer: the module in charge of 
receiving, decoding, and executing instructions. 

See hardware exception. 

The iRMX directory that acts as the default when you specify a 
filename without a preceding pathname. The current directory 
always has the logical name 

A connectionless message-delivery mechanism that does not 
guarantee delivery or the order of delivery. 

A file containing programs and data. See directory file. 

The actual information related to the topic name. Values for the 
data item can be exchanged during conversations. 

The impasse resulting when two or more tasks each hold exclusive 
access to resources needed by the other task(s). 

A network system used exclusively to provide resources to client 
systems. 

A prefix ID used by default whenever a null prefix is presented to 
the I/O system. 

An entry in a descriptor table that contains the physical address, 
length, and other information about an object, which is viewed by 
the Nucleus as the token for the object. It is assigned by the iRMX 
OS when an object is created. 

A hardware-defined table that contains descriptors, which point to 
memory. There are three kinds: a global descriptor table (GDT), 
one or more local descriptor tables (LDT), and an interrupt 
descriptor table (IDT). 
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device 

Hardware connected to the computer system that is used for reading 
and writing data, such as terminals, printers, plotters, display tubes, 
and robots. 

device driver 

Software that controls device operation, and provides a system- 
defined, device-independent interface to the device. Device drivers 
are implemented at the BIOS level. 

directory file 

The type of file that contains the disk addresses of associated data 
files and other directory files. See data file. 

download 

Sending data from a server system to a workstation or end system. 

DUIB 

Device Unit Information Block, a collection of information about a 
device unit (a device and a controller) that includes its name, 
granularity, and addresses of device driver routines. 

dynamic logon 
terminal 

A terminal configured to service many different operators on a 
request-by-request basis. Users log on to the system with a name 
and password. See static logon terminal. 

dynamic memory 
allocation 

Memory that is allocated to jobs only when tasks request it. This 
enables jobs to share memory and change the amount of memory 
they use as their needs change, using less memory overall. See 
static memory allocation. 

dynamic user 

A Human Interface user created by entering a name and password 
on a dynamic logon system. The user must be defined in the UDF 
prior to being created at logon. 

BIOS 

The Extended I/O System. 

end point 

The system at either end of a network communication connection. 
A network system or node. Also called an end system. 

end system 

See end point. 

environment 

The general operating characteristics that are imposed on a 
computer system. 

error code 

Same as a condition code. 

escape sequence 

Characters preceded by an ESC character. 

event 

A system state change. 

exception code 

Same as a condition code. 

exception handler 

A procedure that corrects certain exceptional conditions, or deletes 
or suspends the job that caused the error. 
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exchange object 

extension object 
FIFO 

file consumer 
file driver 

file pointer 

file server 

file system 

file tree 

file types 

firmware 
first level jobs 

fixed updating 

fnode file 

Gbyte 

GOT 


A class of objects used to aid communication, synchronization, and 
mutual exclusion between tasks. See mailboxes, ports, regions, and 
semaphores. 

Designates a new type of object. See composite object. 

First In, First Out order of operation, meaning that the least recent 
item added is the first one removed. 

The iRMX-NET software module that enables a local user to 
transparently access remote files. 

Software that the BIOS uses to control file operation. There is a 
driver for each of the types of files: named, physical, stream, 
remote, DOS, and EDOS. There are also loadable file drivers, such 
as NES. 

An indicator that marks a connection's current position in a file. 

The next sequential read or write starts at the pointer. When a file 
is opened, the pointer is at the beginning of the file. 

The iRMX-NET software module that receives requests from 
remote users. 

A complete hierarchy of logically related files, including a root 
directory. 

A hierarchical file structure that reflects the relationships between 
files. 

There are these types of files in the iRMX OS: named, physical, 
stream, remote, and DOS. 

Software that is permanently fixed onto a memory chip (ROM). 

Children of the root job: some of the OS layers are first level jobs, 
and applications can also be first level jobs. 

Updating done at the same time interval for all devices, with the 
interval being independent of I/O activity. See timeout updating. 

The file descriptor node file, a file in the BIOS that stores 
information about named files, such as the file name, location, 
creation and last modification dates. 

Gigabyte 

Global Descriptor Table, the system-wide table containing 
descriptors that are shared among all jobs in the system. 
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generation output file 

global 

global job 

global object directory 

granule 

granularity 

handshaking 

hardware 

hardware exception 
hardware interrupt 

HI 

home directory 
host 

hot link, DDE 

ICU 

IDT 

initial task 
interoperability 


A file containing the results of the ICU generate command, which 
generates an iRMX system. The file has an .out extension. 

A programming reference that means the same thing throughout the 
entire program. 

An interactive job or user session. 

An object directory, found in each global job, that stores objects 
(including logical names) for that job. These objects remain valid 
for the life of the user job or until they are detached, and other 
users do not have access to them. 

A block of allocated space on a mass storage device. 

The size of a block of allocated space on a mass storage device. 

Signals that are used to synchronize communications equipment 
during the set-up period. 

The physical equipment of a computer system. 

An error that occurs as the result of a hardware protection feature. 

The point at which external processes enter the computer. In the 
iRMX OS, the device that handles hardware interrupts is the 8259A 
Programmable Interrupt Controller (PIC). 

Human Interface, which performs logon and logoff functions, 
creates jobs, assigns memory, and starts initial programs. 

The directory you automatically enter when you log on to the 
iRMX OS. The system manager assigns your home directory when 
initially setting up your account. It has the logical name :home:. 

The CPU board in a computer. 

The server notifies that client that the value of a data item has 
changed. The client immediately receives the new value. 

Interactive Configuration Utility. A screen-oriented utility to help 
build the OS configuration you want. 

Interrupt Descriptor Table, the system-wide table that contains 
descriptors for the system's interrupt handlers. 

The first task to execute after creation of a job. Its sole purpose is 
to initialize the environment for the new job. 

The ability of iRMX-NET to share files with other systems besides 
the iRMX OS. 
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interrupt handler 

interrupt task 
I/O job 

lORS 

I/O system 

iRMX 

iRMX-NET 

ISO 

job 

Kbyte 

LAN 

LOT 

LIFO 

local 

local environment 
local object directory 

local node 


A procedure that is invoked by hardware to respond to an external 
asynchronous event (an interrupt). The handler decides how 
important the interrupt is and either returns to the original task or 
invokes an interrupt task. 

A task that runs when a specific interrupt occurs. 

A job that is a child of the EIOS rather than the Nucleus. I/O jobs 
can use EIOS system calls. 

I/O Request/Result Segment, a device driver data structure created 
to record and control the action taken for each I/O request. 

The layer of an OS that provides input and output functions. The 
iRMX OS has two; the BIOS and the EIOS. 

Intel's Real-time Multitasking Executive, the OS. 

Intel networking software that provides transparent file access 
between systems. 

The International Organization for Standardization. 

One or more tasks and the resources they need (objects, an object 
directory, and a memory pool). 

Kilobyte. 

Local Area Network. An in-house data communications system 
that connects a number of independent devices. 

Local Descriptor Table, a table that stores descriptors and is 
managed by the iRMX OS. 

Last In, First Out order of operation, meaning that the last item 
added is the first one removed. 

In networking, the specific environment that is directly controlled 
by a given computer, such as disk drives and printers attached to a 
system. Local also refers to a user's own system and files, as 
opposed to those available across a network. 

The execution environment for a set of tasks. Same as job. 

When you invoke a command, the OS creates a job and a local 
object directory for that command. The objects cataloged in this 
directory can only be used in the context of this job, and they 
remain valid only until the job exits or is deleted. 

The node a user is logged into is the local node. All other nodes 
are remote nodes. 
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logical name 


LRS 

mailbox 

Mbyte 

media 

memory pool 
MIP 

Multibus 

multiplex 

multiprogramming 

multitasking 

multiuser 

mutual exclusion 

Name Server 

network 

network object 


An identifier (a string of characters, usually bounded on both ends 
by colons) for a file, directory, device, or remote computer system 
that the BIOS associates with a particular file connection or device 
connection. May be either local to a job or global across all jobs. 

Loader Result Segment. Records the action taken by Application 
Loader system calls. 

An object that a task uses to exchange objects, tokens, or 
information with other tasks. There are two kinds: data mailboxes 
and message mailboxes. 

Megabyte. 

The physical parts that store or transport data, such as a CD-ROM, 
or the interconnection between devices attached to a LAN 
(broadband coax, twisted pair, and fiber optics, etc.). 

A configurable amount of memory allocated to a job and its 
children. 

The software module that provides an interface between the local 
CPU board and iNA 960 Transport Software operating on a 
separate network interface controller (NIC). 

Two bus standards (Multibus I and Multibus II) designed and 
supported by Intel for multiprocessor systems. 

To use one structure for more than one function. 

A technique used to independently run several unrelated 
applications on a single application system. 

A type of system that supports the execution of multiple tasks, each 
of which needs control of the processor to run. 

A type of system that enables multiple users to log in and perform 
work as if each were the only user on the system. 

A means of allowing only one task to have access to a shared 
resource at any given time. 

The iRMX-NBT software module that provides the network 
directory service for local and remote users. 

A group of independent computer systems that are interconnected 
for communication. 

A resource that can be accessed over a network by clients, such as 
file servers, print servers, or virtual terminal servers. 
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NFS 


NIC 

node 

non-buffered device 

nonresident user 

Nucleus 
object code 

object directory 

object file 
object module 
objects 

object-based 

OMF 


Network File Support. NFS enables hosts to share their local 
resources with remote hosts (clients) in a manner that hides the 
heterogeneous nature of a network. For example, a server running 
the iRMX OS may share a specific directory with a client machine 
running the Unix OS. The client can access the directory using 
commands and calls that appear to be directed at local resources. 

Network Interface Controller. 

A computer system functioning as the end point in a network. Each 
node is identified by a network address. 

A communications device that must be managed by the host 
processor board. The Terminal Support Code on the host processor 
board must manage the character buffers of the non-buffered 
device. See buffered device. 


A user defined either in the system configuration files or with the 
password command. See resident user. 

The basic layer and computational heart of the iRMX OS. 

Output of a BIND (linker) command or of a compiler such as C, 
PL/M or ASM. 

A place in memory where a task can catalog an object under an 
ASCII name, which can then be used for access instead of the 
object's token. 

A file that contains the binary object code that results from the 
compilation of a program or procedure. 

The output of a single compilation, a single assembly, or a single 
invocation of a BIND command. 


Data structures and the operations performed on them. Objects are 
system building blocks, and include; 


Segments 
Semaphores 
Jobs, I/O jobs 
Tasks 

Buffer pools 
Connections 


Mailboxes 

Regions 

Extension objects 
Composite objects 
Ports 
Users 


A concept that focuses on data structures and the actions performed 
on them. 


Object Module Eormat, the format of linkable modules. 
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operating system 

OS extension 
OSC 

OSI Reference 
Model 


overlays 

owner 

packet 

parameter 

parent directory 
parsing a command 
partition 
pathname 

peer 

peer-to-peer resource 
sharing 

portability 

port 


The software that manages the hardware and logical resources of a 
system, including device handling, scheduling, and file 
management. 

Operating system extension, a way to add custom functions to a 
system to meet the needs of the design. 

Operating System Command: in the context of a terminal driver, a 
sequence of characters used by an application task or the operator 
to communicate with the Terminal Support Code. 

Open Systems Interconnection Reference Model, a model that 
defines network architecture with seven layers: 

1) Physical 5) Session 

2) Data Link 6) Presentation 

3) Network 7) Application 

4) Transport 

Logically independent subsections of a program, which can be 
loaded one at a time in the same block of memory by the AL. 

The user ID associated with a file. 

A group of data bits and control elements that are transmitted 
across a network as a composite whole. 

A variable that can be assigned a constant value for a specific 
function. 

The file directory immediately above the current directory. 

Retrieving and interpreting the parameters of a command. 

An area on a block device such as a disk or tape. 

The designation used by the OS to find or specify a file or 
directory. 

Equivalent computer systems, software modules, or protocol layers. 

In networking, an organization where all the nodes can provide 
resources for each other while also running local applications, so 
each one is both a server and a client. 

Used to describe language processors and software tools that can 
run on several OSs, often because they use UDI system calls. 

An object that can send messages to or receive messages from other 
processors on the same bus. Ports enable message addressing to a 
given task, and are usually used for synchronization. 
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private 

priority 

program state 
PROM 

protected mode 
protocol 

public 

PVAM 

read-ahead 
real address mode 

rebooting 

recovery resident user 
region 


Files, accessed locally, that are not available to remote users across 
a network. 

A number used for scheduling a task relative to other tasks. 
Priorities range from 0 through 255, with 0 being the highest 
priority and 255 the lowest. 

The registers and data used by a program. If the program state is 
saved during task switching, the OS can restart the program later. 

Programmable Read-Only Memory. A memory device in which 
information can be changed after manufacture, but is then 
permanent. 

See PVAM. 

Rules for network communications between equivalent (peer) 
layers in regard to the format and content of the messages 
exchanged. 

Files that are available for access by remote users on a network. 

Protected virtual address mode; microprocessor memory 
management feature that translates virtual addresses to physical 
memory addresses. It supports 4 Gbytes of physical memory. It 
also protects the OS from unauthorized modification by application 
programs, and isolates each user from other users. See real address 
mode. 

A method of overlapping I/O operations so that tasks can continue 
running while the BIOS is transferring information to or from 
devices. See write-behind. 

The method of execution on an Intel386 or later microprocessor 
that supports 1 Mbyte of physical memory in RAM or ROM. The 
iRMX OS does not run in real address mode except for a short time 
when the system boots up. iRMX for Windows switches to Virtual 
86 mode, a form of real mode, to run DOS and its applications. 

See PVAM. 

Resetting the processor without cutting power. Only the contents 
of static memory remain valid after rebooting. 

See resident user. 

An object that controls access to critical areas, such as a collection 
of shared data. A region has special deletion and suspension 
features. Use regions in cases where a section of data must be read 
and written completely by one task before another can access it. 
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remote 

remote node 
resident user 

resources 
response time 

RFD 

root directory 
root module 
root object directory 

round-robin 

scheduling 

run-time linking 

SBC 

SBX 

SDM 

sector 

segment 

semaphore 


In networking, an environment that is not local, or directly 
controlled by a given computer. For example, disk drives and 
printers that are attached to another network system are remote disk 
drives and printers. See local. 

In a network, a node other than the local node. 

A user defined in the Fluman Interface configuration files, which 
gains control only if an initialization error occurs in the 
configuration files. Same as recovery resident user. See 
nonresident user. 

The data and devices on a server that may be accessed by a client. 

The time it takes between the occurrence of an event or interrupt 
and the system's response to it. 

Remote File Driver is part of the BIOS subsystem and closely 
parallels the Named File Driver of the local OS. 

The topmost directory in a hierarchical file system. 

An object module that controls the loading of overlays. 

An object directory for the root job, containing logical names for 
devices. These objects remain valid until they are detached or the 
system is reinitialized, and every user has access. 

A priority-based time-slicing system of scheduling tasks for 
processing. Multiple tasks of equal priority are each allotted the 
same amount of execution time, and alternate running until 
finished. 

Letting each program know the locations of the variables and 
procedures that it uses while the system is actually running. 

Single Board Computer. 

Single Board Expansion Module. 

System Debug Monitor, a software debugging tool. 

A device granule (block of allocated space) for disk media. 

A contiguous unit of memory addressed by a descriptor. Tasks use 
segments for purposes such as stacks, data storage, and buffers. 

An object that is a counter, and provides a very fast method of task 
synchronization, or can be used for mutual exclusion. 
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server, DDE 

server, network 
session 
spokesman 
stack 

start-up systems 

static logon 
terminal 

static memory 
allocation 

static user 
stream file 
string 

subnetwork 

subtree 
Super user 


The application that starts a DDE conversation by issuing a query. 
An iRMX application can be a server for one conversation and a 
client for another. 

A network system that responds to and provides the resources that 
are requested and accessed by a client system. 

In networking, a point-to-point (virtual-circuit) connection between 
peer systems. 

In networking, the system that contains the names and addresses of 
other systems. 

An ordered collection of items in memory, into which new items 
may be inserted or removed. When a program makes a call, data is 
passed or stored on the program’s stack. Stacks are LIEO (last in, 
first out) meaning that the most recent item added is the first one 
removed. 

Bootable images of the iRMX OS that are ready to run. 

A terminal configured to service one specific user. The logon is 
invisible to the user. See dynamic logon terminal. 

A memory-allocation method in which memory is allocated to jobs 
when the system is started, and cannot be freed for other jobs. 

Thus, the total memory requirement of the system is always the 
sum of the memory requirements of all jobs. See dynamic memory 
allocation. 

A user that comes up automatically when a static logon system is 
booted. 

A temporary stream of bytes in memory, which is read on a EIEO 
basis and destroyed after reading. 

An iRMX string is a character string consisting of \+n consecutive 
bytes. The first byte contains the character count. The following n 
bytes contain the ASCII codes for the characters. 

This is different from a C string, which is null terminated; there is 
no count byte and the string ends at the first byte containing zero. 

Synonym for Administrative Unit (AU) used by UNIX and other 
OSs. 

All the data files and nested directories contained in a directory. 

Usually the system administrator; has a user ID of 0 and access to 
all files and devices on the system. 
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SXM 

synchronization 

synchronous 


synchronous system 
call 

system 

system call 

system manager 

task 

task priority 
task switching 

TCP 

TCP/IP 

Telnet 

Terminal Support 
Code (TSC) 

TFTP 


System Extension Module. 

A programming technique that enables dependent tasks to take 
turns in their use of shared data or system resources. 

At precisely the same time. An event or device that is in time with 
the CPU or another device. In networking, a method by which 
signals between systems are timed, with a pre-arranged number of 
bits per second being sent across the communications line. See 
asynchronous. 

A call that must complete before control of the computer is 
returned to the calling task. See asynchronous system call. 

All the hardware and software components of a given computer. 

A programmatic interface used to manipulate objects or control the 
computer's actions. 

The Super user, with an ID of 0, who defines users and systems 
within an Administrative Unit. 

System activities that execute instructions and manipulate data. 

Can be viewed as a simple program that appears to be running on a 
computer by itself. 

A value from 0 through 255, with 0 being the highest priority. 

Used in task scheduling along with the task state. 

Temporarily stopping one task and running another. The registers 
and data (called the program state) of the first task are saved, and it 
can be resumed later at the same point at which it was interrupted. 

Transmission Control Protocol. A transport layer protocol for the 
Internet. It is a connection-oriented, stream protocol defined by 
RFC 793. 

Transmission Control Protocol/Internet Protocol. A set of computer 
networking protocols and applications that enables two or more 
hosts to communicate. TCP/IP includes a suite of protocols besides 
TCP and IP; it has been widely adopted as a networking standard. 

A TCP/IP protocol used for remote login between hosts. 

A set of commands that control terminal modes and operation. 


Trivial File Transfer Protocol. A standard for transferring files 
between hosts. TFTP lacks the error-checking and user- 
authentication facilities offered by FTP. 
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timeout updating 


time-slicing 


token 


top-down 

programming 


topic name, DDE 


transparency 

trap 

TSC 

UA 

UDF 

UDI 

user 

user job 
verified client 


Updating done at intervals set individually for each device, with the 
interval beginning at the end of each I/O operation. See fixed 
updating. 

A non-priority-based system of scheduling tasks for processing. 
Multiple tasks are each allotted the same amount of execution time, 
and alternate running until finished. 

A value representing the logical address and the characteristics of 
an object. See descriptor. 

A programming concept that focuses on control flow, in contrast to 
object-based programming, which focuses on data structures and 
the processes performed on them. See object-based programming. 

The general classification of data items which may be exchanged 
during a DDE conversation. This is usually either a filename, if the 
conversing applications exchange files, or an application-specific 
name. 

Remote file access that enables the user application to manipulate 
remote files as if they were local. 

See hardware exception. 

Terminal Support Code, a set of commands that control terminal 
modes and operation. 

User Administration. The iRMX-NET software module that 
maintains the files used by a system manager when making 
additions and deletions of users and systems in an iRMX-NET 
environment. 

User Definition File. An iRMX OS file that contains information 
about valid users of a system. Used by the server system in 
maintaining the server-based protection scheme. 

Universal Development Interface acts as an interface between the 
OS and the application program. 

Used by iRMX to determine access rights to files and systems. A 
user job is created when an operator logs onto a system to obtain 
access to the system. 

A child job of the HI. 

A client system verified by a server as a node entitled to access the 
server. 
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verified user 
Virtual 86 mode 
virtual circuit 

virtual root directory 

VM86 Dispatcher 
volume 

warm link, DDE 
wildcard character 
write-behind 


A dynamically logged-on user. Verification only has meaning 
when the user is attempting to access remote files using a network. 

A form of real mode used by iRMX for Windows to run DOS and 
its applications. 

A reliable, connection-oriented message delivery service. A 
connection through the Transport Layer of the OSI Reference 
Model that delivers error-free, point-to-point messages in the same 
sequence as the messages are sent. 

The root directory of a remote server system, as seen from the 
client system. 

Allows DOS to run as a task under iRMX for Windows. 

The medium used to store information on a device, such as a 
diskette, tape reel, or hard disk. 

The server notifies the client that the value of a data item has 
changed. However, the server waits until the client requests that it 
be sent the new value. 

A character that can substitute for any single character (typically ?) 
or any sequence of characters (typically *), providing the ability to 
specify several files in a single reference. 

A method of overlapping I/O operations that enables tasks to 
continue running while the BIOS is transferring information to or 
from devices. See read-ahead. 


□ □ □ 
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A 

access, controlling user, example, 63 
access mode, control in connections, 64 
access rights 

for DOS/iRMX files, 69 
for NFS files, 69 
addressing modes, 32 
Administrative Unit, see AU 
Aedit, see Programming Techniques and Aedit 
Text Editor manual 
AL (Application Loader), 93 

asynchronous/synchronous system 
calls, 95 
description, 93 

dynamic loading from devices, 94 
overlay modules, 96 
alarms. Kernel, 57 
allocating, memory, 26 
application development, 107 
debugging, 115 
design, 109 
examples. 111 
networking, 104 
Application Loader, see AL 
asynchronous system calls 
definition, in BIOS, 67 
inAL, 95 

AU (Administrative Unit) 
definition of, 102 

automatic reattachment of devices, 76 

B 

Basic I/O System, see BIOS 
BIOS (Basic I/O System) 
advantages, 79 
compared with BIOS, 79 
system call types, 67 
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blocking, buffers, 76 
bootstrap loading, 114 
buffer pools, 43 
with ports, 47 
buffering 

algorithm, custom, 79 
I/O, 76 
buffers 

and granularity, 75 
choosing number of, 76 
I/O, 76 
type-ahead, 77 
bus architectures, 34 

c 

C Library 

and I/O systems, 80 
calls from I/O jobs, 66 
overview, 108 
call gates, 49 

CDL (Client Definition File), 102 
CLI (Command Line Interpreter) 
features, 91 

special function keys, 92 
client, 103 

and server, networking, 103 
name, iRMX-NET, 102 
clock 

global, 78 
local, 78 

code portability, 98 

command lines, parsing, example, 87 

communicating 

between DOS and iRMX, 35, 104 
between tasks, 23, 71 
composite objects, 48 
condition codes, 55 
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configuration 

definition, 119 
iRMXforPCs, 120 
iRMX for Windows, 120 
iRMXIII, 119 
connections, 76 

and access mode, 64 
device, 65 
file, 64 

controlling, devices, 74 

cursor, moving, 92 

customer support, inside back cover 

D 

data, validity of, 25 
data packets, 34 
deadlock, 46 
debugging tools, 115 

System Debug Monitor, 1 15 
System Debugger, 1 16 
default user object, definition, 62 
descriptor, 49 

designing application system, guidelines, 109 
determinism, 18 
device connections, 65 
device drivers 

definition, 73 
loadable, 120 
device granularity, 75 
devices 

automatic reattachment, 76 
control, 74 

independence, definition, 72 
logical names, 66 
disk integrity, 74 
DOS, networking, 103 
DOS files 

definition, 70 
remote access, 104 
drivers, see device drivers, file drivers 
dynamic loading 
inAL, 94 
loadable jobs, 120 

dynamic logon terminal, definition, 89 


E 

BIOS (Extended I/O System) 
advantages, 79 
compared with BIOS, 79 
escape sequences, 77 
event-driven applications, 16 
examples 

application systems. 111 
interrupt handlers, 54,112 
multitasking, 112 
mutual exclusion, 45, 46 
parsing commands, 87 
regions, 46 
semaphores, 45 
synchronizing tasks, 24 
user access control, 63 
exception handlers, 55 
exchanging information 

between DOS and iRMX, 35 
between tasks, 23 
execution state, 5 1 
Extended I/O System, see BIOS 
extension objects, 48 

F 

file connections, 64 
file drivers 

definition, 72 
loadable, 120 
file fragmentation 
controlling, 75 
file granularity, 75 
file integrity, 74 
file pointers, 65 
files 

access control of, user, 62 
access rights to, 69 
and multiple users, 68 
concurrent access to, 65 
hierarchical, 68 
independence of, 70 
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logical names of, 66 
types of 

DOS, 70 
named, 70 
physical, 71 
remote, 70 
stream, 71 
updating, 74 

fixed updating, definition, 74 
flat model, 27 

G 

global clock, 78 

granularity, types of, 75 

guidelines for designing applications, 109 

H 

hardware environments, networking, 101 
HI (Human Interface) 
description, 83 
operation, 89 
HI command, 85 
hierarchical files, 68 
Human Interface, see HI 

I 

I/O 

buffering, 76 
overlapping, 76 
random-access, 76 
redirecting, 92 
sequential, 76 
I/O jobs 

and AL, 95 
definition in BIOS, 66 
ICU (Interactive Configuration Utility), 119 
advantages, 120 
online help, 108 
1NA960, 101,104 

Transport Software, 101 
initial program, 9 1 

installing iRMX, see Installation and Startup 
manual 


interactive command, custom, 86 
Interactive Configuration Utility, see ICU 
interoperability, 103 
interrupt handlers, 16,53 
examples, 54, 112 
interrupt response time, 18 
interrupt task, when used, 54 
intertask communication, 7 1 
iRMX 

compatibility, 67 
configuration, 119 
features and functions, 12 
layers, 28 
iRMX for PCs 

configuration, 120 
features, 36 
iRMX for Windows 
configuration, 120 
features, 35 
memory access, 35 
networking, 104 
Novell compatibility, 104 

J 

jobs, 38 

loadable, 120 
loading, 84 
operator or user, 90 
tree, 38 

K 

Kernel 

features, 57 
task management, 58 
time management, 58 
when to use, 59 

L 

languages, 107 

layers of operating system, 28 

libraries, UDI, 98 

limitations, maximum objects in system, 38 
loadable jobs, 120 
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loading 

jobs, 84 

overlay modules, 96 
local clock, 78 
logical names 

cataloging, 66 
definition, 66 
logon, process, 89 

M 

mailboxes 

Kernel, 57 
Nucleus, 44 
manuals 

iRMX, 121 
on CD, 108 
memory 

allocating and sharing, 26 
and physical files, 71 
and stream files, 71 
conserving, 94, 96 
protection, 33 
memory access 

iRMX for Windows, 35 
memory pools, 41 

Kernel requirements, 57 
memory segments, 42 
microcomputers, 1 1 
microprocessors, 11 

addressing modes, 32 
protection features, 33 
modular programming, 13 
Multibus I 

features, 34 

supported by iRMX-NET, 
Multibus II 

features, 34 

supported by iRMX-NET, 
multiple terminals, support, 88 
multiprogramming, 19 
multitasking, 13 
examples, 1 12 
multiuser support, 88, 89 
mutual exclusion, 25 
examples, 45, 46 


N 


named files, 70 
NetBIOS, 104 

NetRDR (Network Redirector), 104 
network, 31 

applications, DOS, 104 
between operating systems, 103 
controllers, 104 
definition of, 99 
hardware, 101 

Network File Access (NFA) protocols, 103 
Novell NetWare, 104 
Nucleus, functions, 37 


o 

object directories, 40, 49, 66 
Object Module Format (OMF), 97 
objects 

definitions, 37 
maximum in system, 38 
types, 21 
user-created, 48 

OMF (Object Module Format), 97 
online help, 108 
online help command, 108 
on-target development, 107 
OpenNET, 103 

operating systems, switching between, 98 
overlapping 
I/O, 76 

processing in AF, 95 
overlay modules, definition, 96 

101 p 

packets, data, 34 

101 page fault, 33 

page tables, 33 
paging subsystem, 27 
password, defined in CDF, 102 
PC Bus, 101 
PC features, 34 
physical files, definition, 71 
pointers, to locations in files, 65 
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portability 

of applications, 104 
of code, 98 
ports, 47 

preemptive schedules, 14 
priority-based schedules, 14 
program development, see application 
development 

protected mode, see PVAM 

PVAM (protected virtual address mode), 32 

R 

RAM, 114 
random-access I/O 
and buffers, 76 
read-ahead, 76 
real mode, 32 
real-time response, 12 
recalling command, 92 
recalling commands, 92 
redirecting, I/O, 92 
regions 

Kernel, 57 
Nucleus, 46 
remote files 

access, 104 
definition, 70 

response time, predictable, 18 
ROM, 114 

round-robin schedules, 52 

s 

sectors and granularity, 75 
segments, 42 
semaphores 
Kernel, 57 
Nucleus, 45 
sequential I/O 

and buffers, 76 

server, and client, networking, 103 
service information, inside back cover 
sharing, memory, 26 
Soft-Scope debugger, 116,117 
standard initial program, 9 1 
start-up systems, 119 


static logon terminal, definition, 89 
stream files, definition, 71 
switching, operating systems, 98 
synchronizing, tasks, 24 
synchronous system calls 
definition, in BIOS, 67 
inAL, 95 
system calls 

asynchronous/synchronous in AL, 95 
asynchronous/synchronous in BIOS, 67 
definition, 27 

differences between BIOS and BIOS, 66 
online help, 108 
prefixes, 67 
system clock, 78 
system configuration, 119 
System Debug Monitor (SDM), 115 
System Debugger (SDB), 116 

T 

task states, 18 
task switch time, 18 
tasks, 42 

communication, 23 
concurrent access to file, 65 
coordination, 23 
message passing, 23 
priority of, 5 1 
scheduling, 50 
synchronizing, 24 
termcap file, 91 

Terminal Support Code, see TSC 
terminals 

controlling output, 77 
dynamic and static, definition, 89 
setting variables, 77 
support for multiple, 89 
support for various types, 91 
timeout updating, definition, 74 
tokens, 49 
tools, 107 

top-down programming, 13 
translation, definition, 77 
transparent mode, 77 
transporting code between OSs, 98 
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TSC (Terminal Support Code) 
definition and functions, 77 
type manager, 48 
type-ahead 
buffer, 77 
inCLI, 92 
typing input, 92 

u 

UDF (User Definition File), 102 
UDI (Universal Development Interface) 
libraries, 98 

Universal Development Interface, see UDI 
UNIX, networking, 103 


updating files, fixed and timeout, 74 
User Definition File, see UDF 
user ID, 102 
user job, 90 

V 

virtual memory, 27 
volumes 

and physical files, 71 
integrity, 74 

w 

write-behind, 76 


X 

X.25 network options, 105 
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